https://wiki.mikrotik.com/api.php?action=feedcontributions&user=Megis&feedformat=atomMikroTik Wiki - User contributions [en]2024-03-29T02:19:48ZUser contributionsMediaWiki 1.38.2https://wiki.mikrotik.com/index.php?title=Manual:Product_Naming&diff=31686Manual:Product Naming2018-07-17T10:27:11Z<p>Megis: </p>
<hr />
<div>==Naming details for RouterBOARD products==<br />
<br />
RouterBOARD (short version RB)<br />
<br />
<code><board name> <board features>-<built-in wireless> <wireless card features>-<connector type><br />-<enclosure type></code><br />
<br />
===Board Name===<br />
<br />
Currently there can be three types of board names:<br />
<br />
* '''3-symbol name'''<br />
** 1st symbol stands for series (this can either be a number or a letter)<br />
** 2nd digit for indicating number of potential wired interfaces (Ethernet, SFP, SFP+)<br />
** 3rd digit for indicating number of potential wireless interfaces (built-in and mPCI and mPCIe slots)<br />
<br />
* '''Word''' - currently used names are: '''OmniTIK, Groove, SXT, SEXTANT, Metal, LHG, DynaDish, cAP, wAP, LDF, DISC, mANTBox, QRT, DynaDish, cAP, hAP, hEX '''. If board has fundamental changes in hardware (such as completely different CPU) revision version will be added in the end<br />
<br />
* '''Exceptional naming''' - 600, 800, 1000, 1100, 1200, 2011, 3011 boards are standalone representatives of the series or have more than 9 wired interfaces, so name was simplified to full hundreds or development year.<br />
<br />
===Board Features===<br />
<br />
Board features follows immediately after board name section (no spaces or dashes), except when board name is a word, then board features are separated by space.<br />
<br />
<br />
Currently used features (listed in order they are used):<br />
* '''U''' - USB<br />
* '''P''' - power injection with controller<br />
* '''i''' - single port power injector without controller<br />
* '''A''' - more memory (and usually higher license level)<br />
* '''H''' - more powerful CPU<br />
* '''G''' - Gigabit (may include "U","A","H", if not used with "L")<br />
* '''L''' - light edition <br />
* '''S''' - SFP port (legacy usage - SwitchOS devices)<br />
* '''e''' - PCIe interface extension card<br />
* '''x<N>''' - where N is number of CPU cores ( x2, x16, x36 etc)<br />
* '''R''' - MiniPCI or MINIPCIe slot<br />
<br />
===Built-in wireless details===<br />
<br />
If board has built-in wireless, then all its features are represented in following format:<br />
<br />
<code><band><power_per_chain><protocol><number_of_chains></code><br />
<br />
* '''band'''<br />
** '''5''' - 5Ghz<br />
** '''2''' - 2.4Ghz<br />
** '''52''' - dual band 5Ghz and 2.4Ghz<br />
<br />
* '''power per chain'''<br />
** (not used) - "Normal" - <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g<br />
** '''H''' - "High" - 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g<br />
** '''HP''' - "High Power" - 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g<br />
** '''SHP''' - "Super High Power" - 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g<br />
<br />
* '''protocol'''<br />
** (not used) - for cards with only 802.11a/b/g support<br />
** '''n''' - for cards with 802.11n support<br />
** '''ac''' - for cards with 802.11ac support<br />
<br />
* '''number_of_chains'''<br />
** (not used) - single chain<br />
** '''D''' - dual chain<br />
** '''T''' - triple chain<br />
<br />
* '''connector type'''<br />
** (not used) - only one connector option on the model<br />
** '''MMCX''' - MMCX connector type<br />
** '''u.FL''' - u.FL connector type<br />
<br />
===Enclosure type===<br />
<br />
* (not used) - main type of enclosure for a product<br />
* '''BU''' - board unit (no enclosure) - for situation when board-only option is required, but main product already comes in the case<br />
* '''RM''' - rack-mount enclosure<br />
* '''IN''' - indoor enclosure<br />
* '''EM''' - extended memory<br />
* '''LM''' - light memory<br />
* '''BE''' - black edition case<br />
* '''TC''' - Tower (vertical) case<br />
* '''OUT''' - outdoor enclosure<br />
<br />
===More Specific types '''OUT''' enclosures are:===<br />
<br />
* '''SA''' - sector antenna enclosure (for SXT)<br />
* '''HG''' - high gain antenna enclosure (for SXT)<br />
* '''BB''' - Basebox enclosure (for RB911)<br />
* '''NB''' - NetBox enclosure (for RB911)<br />
* '''NM''' - NetMetal enclosure (for RB911)<br />
* '''QRT''' - QRT enclosure (for RB911)<br />
* '''SX''' - Sextant enclosure (for RB911,RB711)<br />
* '''PB''' - PowerBOX enclosure (for RB750P, RB950P)<br />
* '''PC''' - PassiveCooling enclosure (for CCR)<br />
* '''TC''' - Tower (vertical) Case enclosure (for hEX, hAP and other home routers.)<br />
<br />
===Example===<br />
<br />
Lets decode [http://routerboard.com/RB912UAG-5HPnD RB912UAG-5HPnD] naming<br />
<br />
* RB (RouterBOARD)<br />
* 912 - 9th series board with 1 wired (ethernet) interface and two wireless interfaces (built-in and miniPCIe)<br />
* UAG - has USB port, more memory and gigabit ethernet port<br />
* 5HPnD - has built in 5GHz high power dual chain wireless card with 802.11n support.<br />
<br />
==CloudCoreRouter naming details==<br />
<br />
CloudCoreRouter (short version CCR) naming consists of:<br />
<br />
<code><4 digit number>-<list of ports>-<enclosure type></code><br />
<br />
* '''4 digit number'''<br />
**1st digit stands for series<br />
**2nd (reserved)<br />
**3rd-4th digit indicate number of total CPU cores on the device<br />
<br />
* '''list of ports'''<br />
**-<n>G number of 1G Ethernet ports<br />
**-<n>P number of 1G Ethernet ports with PoE-out<br />
**-<n>C number of combo 1G Ethernet/SFP ports<br />
**-<n>S number of 1G SFP ports<br />
**-<n>G+ number of 2.5G Ethernet ports<br />
**-<n>P+ number of 2.5G Ethernet ports with PoE-out<br />
**-<n>C+ number of combo 10G Ethernet/SFP ports<br />
**-<n>S+ number of 10G SFP+ ports<br />
**-<n>XG number of 5G/10G Ethernet ports<br />
**-<n>XP number of 5G/10G Ethernet ports with PoE-out<br />
**-<n>XC number of combo 10G/25G SFP+ ports<br />
**-<n>XS number of 25G SFP+ ports<br />
**-<n>Q+ number of 40G QSFP+ ports<br />
**-<n>XQ number of 100G QSFP+ ports<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
==CloudRouterSwitch and CloudSmartSwitch naming details==<br />
<br />
CloudRouterSwitch (short version CRS, RouterOS device) CloudSmartSwitch (short version CSS, SwOS device) naming consists of:<br />
<br />
<code><3 digit number>-<list of ports>-<built-in wireless card>-<enclosure type></code><br />
<br />
* '''3 digit number'''<br />
**1st digit stands for series<br />
**2nd-3rd digit - total number of wired interfaces (Ethernet, SFP, SFP+)<br />
<br />
* '''list of ports'''<br />
**-<n>G number of 1G Ethernet ports<br />
**-<n>P number of 1G Ethernet ports with PoE-out<br />
**-<n>C number of combo 1G Ethernet/SFP ports<br />
**-<n>S number of 1G SFP ports<br />
**-<n>G+ number of 2.5G Ethernet ports<br />
**-<n>P+ number of 2.5G Ethernet ports with PoE-out<br />
**-<n>C+ number of combo 10G Ethernet/SFP ports<br />
**-<n>S+ number of 10G SFP+ ports<br />
**-<n>XG number of 5G/10G Ethernet ports<br />
**-<n>XP number of 5G/10G Ethernet ports with PoE-out<br />
**-<n>XC number of combo 10G/25G SFP+ ports<br />
**-<n>XS number of 25G SFP+ ports<br />
**-<n>Q+ number of 40G QSFP+ ports<br />
**-<n>XQ number of 100G QSFP+ ports<br />
<br />
* '''built-in wireless card''' - same as for [[#Built-in_wireless_details | RouterBOARD products]].<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category: Routerboard|Naming]]<br />
[[Category: Manual|Naming]]<br />
[[Category:Basic|Naming]]<br />
[[Category:Hardware|Naming]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Product_Naming&diff=28715Manual:Product Naming2016-10-13T12:39:49Z<p>Megis: </p>
<hr />
<div>==Naming details for RouterBOARD products==<br />
<br />
RouterBOARD (short version RB)<br />
<br />
<code><board name> <board features>-<built-in wireless> <wireless card features>-<connector type><br />-<enclosure type></code><br />
<br />
===Board Name===<br />
<br />
Currently there can be three types of board names:<br />
<br />
* '''3-digit number'''<br />
** 1st digit stands for series<br />
** 2nd digit for indicating number of potential wired interfaces (Ethernet, SFP, SFP+)<br />
** 3rd digit for indicating number of potential wireless interfaces (built-in and mPCI and mPCIe slots)<br />
<br />
* '''Word''' - currently used names are: '''OmniTIK, Groove, SXT, SEXTANT, Metal, LHG, DynaDish, cAP, wAP, '''. If board has fundamental changes in hardware (such as completely different CPU) revision version will be added in the end<br />
<br />
* '''Exceptional naming''' - 600, 800, 1000, 1100, 1200, 2011, 3011 boards are standalone representatives of the series or have more than 9 wired interfaces, so name was simplified to full hundreds or development year.<br />
<br />
===Board Features===<br />
<br />
Board features follows immediately after board name section (no spaces or dashes), except when board name is a word, then board features are separated by space.<br />
<br />
<br />
Currently used features (listed in order they are used):<br />
* '''U''' - USB<br />
* '''P''' - power injection with controller<br />
* '''i''' - single port power injector without controller<br />
* '''A''' - more memory (and usually higher license level)<br />
* '''H''' - more powerful CPU<br />
* '''G''' - Gigabit (may include "U","A","H", if not used with "L")<br />
* '''L''' - light edition <br />
* '''S''' - SFP port (legacy usage - SwitchOS devices)<br />
* '''e''' - PCIe interface extension card<br />
* '''x<N>''' - where N is number of CPU cores ( x2, x16, x36 etc)<br />
* '''R''' - MiniPCI or MINIPCIe slot<br />
<br />
===Built-in wireless details===<br />
<br />
If board has built-in wireless, then all its features are represented in following format:<br />
<br />
<code><band><power_per_chain><protocol><number_of_chains></code><br />
<br />
* '''band'''<br />
** '''5''' - 5Ghz<br />
** '''2''' - 2.4Ghz<br />
** '''52''' - dual band 5Ghz and 2.4Ghz<br />
<br />
* '''power per chain'''<br />
** (not used) - "Normal" - <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g<br />
** '''H''' - "High" - 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g<br />
** '''HP''' - "High Power" - 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g<br />
** '''SHP''' - "Super High Power" - 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g<br />
<br />
* '''protocol'''<br />
** (not used) - for cards with only 802.11a/b/g support<br />
** '''n''' - for cards with 802.11n support<br />
** '''ac''' - for cards with 802.11ac support<br />
<br />
* '''number_of_chains'''<br />
** (not used) - single chain<br />
** '''D''' - dual chain<br />
** '''T''' - triple chain<br />
<br />
<br />
* '''connector type'''<br />
** (not used) - only one connector option on the model<br />
** '''MMCX''' - MMCX connector type<br />
** '''u.FL''' - u.FL connector type<br />
<br />
<br />
===Enclosure type===<br />
<br />
* (not used) - main type of enclosure for a product<br />
* '''BU''' - board unit (no enclosure) - for situation when board-only option is required, but main product already comes in the case<br />
* '''RM''' - rack-mount enclosure<br />
* '''IN''' - indoor enclosure<br />
* '''EM''' - extended memory<br />
* '''LM''' - light memory<br />
* '''BE''' - black edition case<br />
* '''TC''' - Tower (vertical) case<br />
* '''OUT''' - outdoor enclosure<br />
<br />
===More Specific types '''OUT''' enclosures are:===<br />
<br />
* '''SA''' - sector antenna enclosure (for SXT)<br />
* '''HG''' - high gain antenna enclosure (for SXT)<br />
* '''BB''' - Basebox enclosure (for RB911)<br />
* '''NB''' - NetBox? enclosure (for RB911)<br />
* '''NM''' - NetMetal? enclosure (for RB911)<br />
* '''QRT''' - QRT enclosure (for RB911)<br />
* '''SX''' - Sextant enclosure (for RB911,RB711)<br />
* '''PB''' - PowerBOX enclosure (for RB750P, RB950P)<br />
* '''PC''' - PassiveCooling enclosure (for CCR)<br />
* '''TC''' - Tower (vertical) Case enclosure (for hEX, hAP and other home routers.)<br />
<br />
===Example===<br />
<br />
Lets decode [http://routerboard.com/RB912UAG-5HPnD RB912UAG-5HPnD] naming<br />
<br />
* RB (RouterBOARD)<br />
* 912 - 9th series board with 1 wired (ethernet) interface and two wireless interfaces (built-in and miniPCIe)<br />
* UAG - has USB port, more memory and gigabit ethernet port<br />
* 5HPnD - has built in 5GHz high power dual chain wireless card with 802.11n support.<br />
<br />
==CloudCoreRouter naming details==<br />
<br />
CloudCoreRouter (short version CCR) naming consists of:<br />
<br />
<code><4 digit number>-<list of ports>-<enclosure type></code><br />
<br />
* '''4 digit number'''<br />
**1st digit stands for series<br />
**2nd (reserved)<br />
**3rd-4th digit indicate number of total CPU cores on the device<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
==CloudRouterSwitch and CloudSmartSwitch naming details==<br />
<br />
CloudRouterSwitch (short version CRS, RouterOS device) CloudSmartSwitch (short version CSS, SwOS device) naming consists of:<br />
<br />
<code><3 digit number>-<list of ports>-<built-in wireless card>-<enclosure type></code><br />
<br />
* '''3 digit number'''<br />
**1st digit stands for series<br />
**2nd-3rd digit - total number of wired interfaces (Ethernet, SFP, SFP+)<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''built-in wireless card''' - same as for [[#Built-in_wireless_details | RouterBOARD products]].<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category: Routerboard|Naming]]<br />
[[Category: Manual|Naming]]<br />
[[Category:Basic|Naming]]<br />
[[Category:Hardware|Naming]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28395Manual:HTB-Token Bucket Algorithm2016-05-13T08:06:46Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.35+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on the "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at a specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option was added in RouterOS v6.35, before that it was hard-coded to a value of "0.1".<br />
<br />
Before allowing any packet to pass through the queue, the queue bucket is inspected to see if it already contains sufficient tokens at that moment.<br />
<br />
If yes, the appropriate number of tokens are removed ("cashed in") and packet is permuitted to pass through the queue.<br />
<br />
If no, the packets stays at the start of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
In case of a multi-level queue structure, tokens used in a child queue are also 'charged' to their parent queues.<br />
In other words - child queues 'borrow' tokens from their parent queues.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
The size of this packet queue, the sequence, how packets are added to this queue, and when packets are discarded are determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the 'burst' is active<br />
<br />
'''burst-limit''' is active only when 'burst' is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case where '''limit-at''' is the highest value, extra tokens need to be issued to compensate for all missing tokens that were not borrowed from it's parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]<br />
<br />
==Bucket Size in action==<br />
<br />
Lets have a simple setup where all traffic from and to one IP address is marked with a packet-mark:<br />
<br />
<pre><br />
/ip firewall mangle<br />
add chain=forward action=mark-connection connection-mark=no-mark src-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-connection connection-mark=no-mark dst-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-packet connection-mark=pc1_conn new-packet-mark=pc1_traffic<br />
</pre><br />
<br />
===Default Queue Bucket===<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M<br />
</pre><br />
<br />
In this case bucket-size=0.1, so bucket-capacity= 0.1 x 10M = 1M<br />
<br />
If the bucket is full (that is, client was not using full capacity of the queue for some time), the next 1Mb of traffic can pass through the queue at an unrestricted speed.<br />
<br />
===Large Queue Bucket===<br />
<br />
Lets try to apply the same logic to a situation when bucket-size is at its maximal value:<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M<br />
<br />
If the bucket is full (that is, client was not using full capacity of the queue for some time), the next 100Mb of traffic can pass through the queue at an unrestricted speed.<br />
<br />
So you can have:<br />
* 20Mbps transfer speed for 10s<br />
* 60Mbps transfer burst for 2s<br />
* 1Gbps transfer burst for approximately 100ms<br />
<br />
You can therefore see that the bucket permits a type of 'burstiness' of the traffic that passes through the queue.<br />
The behavior is similar to the normal burst feature, but lacks the upper limit of the burst.<br />
This setback can be avoided if we utilize bucket size in the queue structure:<br />
<br />
===Large Child Queue Bucket, Small Parent Queue Bucket ===<br />
<br />
<pre><br />
/queue tree<br />
add name=download_parent parent=Local max-limit=20M<br />
add name=download parent=download_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload_parent parent=Public max-limit=20M<br />
add name=upload parent=upload_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case: <br />
*parent queue bucket-size=0.1, bucket-capacity= 0.1 x 10M = 1M<br />
*child queue bucket-size=10, bucket-capacity= 10 x 10M = 100M<br />
<br />
The parent will run out of tokens much faster than child queue and as its child queue always borrows tokens from parent queue the whole system is restricted to token-rate of the parent queue - in this case to max-limit=20M. This rate will be sustained until the child queue runs out of tokens and will be restricted to its token-rate of 10Mbps.<br />
<br />
In this way we can have a burst at 20Mbps for up to 10 seconds.</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28393Manual:HTB-Token Bucket Algorithm2016-05-12T09:21:39Z<p>Megis: /* Token Bucket algorithm (Red part of the diagram) */</p>
<hr />
<div>{{Versions|v6.35+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the queue bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
In case of queue structure tokens used in a child queue are charged to parent queues also.<br />
in other words - children queues borrow tokens from their parent queues.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was the highest, extra tokens need to be issued to compensate for all missing tokens that were not borrowed from parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]<br />
<br />
==Bucket Size in action==<br />
<br />
Lets have a simple setup where all traffic from and to one IP address is marked with a packet-mark:<br />
<br />
<pre><br />
/ip firewall mangle<br />
add chain=forward action=mark-connection connection-mark=no-mark src-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-connection connection-mark=no-mark dst-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-packet connection-mark=pc1_conn new-packet-mark=pc1_traffic<br />
</pre><br />
<br />
===Default Queue Bucket===<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M<br />
</pre><br />
<br />
In this case bucket-size=0.1, so bucket-capacity= 0.1 x 10M = 1M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 1Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
===Large Queue Bucket===<br />
<br />
Lets try to apply same logic to situation when bucket-size is at its maximal value:<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 100Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
So you can have:<br />
* 20Mbps transfer speed for 10s<br />
* 60Mbps transfer burst for 2s<br />
* 1Gbps transfer burst for ~100ms<br />
<br />
So as you can see bucket permits certain burstiness of the traffic that passes the queue.<br />
So behavior is similar to our burst feature, but lacks the upper limit of the burst.<br />
But this setback can be avoided when we utilize bucket size in queue structure:<br />
<br />
===Large Child Queue Bucket, Small Parent Queue Bucket ===<br />
<br />
<pre><br />
/queue tree<br />
add name=download_parent parent=Local max-limit=20M<br />
add name=download parent=download_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload_parent parent=Public max-limit=20M<br />
add name=upload parent=upload_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case: <br />
*parent queue bucket-size=0.1, bucket-capacity= 0.1 x 10M = 1M<br />
*child queue bucket-size=10, bucket-capacity= 10 x 10M = 100M<br />
<br />
So parent will run out of tokens much faster than child queue and, as child queue always borrows tokens from parent queue, whole system is restricted to token-rate of the parent queue - in this case to max-limit=20M, this rate will be sustained until child queue runs out of the tokens and will be restricted to its token-rate 10Mbps.<br />
<br />
So this way we can have up to 10 second burst at 20Mbps</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28392Manual:HTB-Token Bucket Algorithm2016-05-12T08:25:27Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.35+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the queue bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
In case of queue structure tokens used in a child queue are charged to parent queues also.<br />
in other words - children queues borrow tokens from their parent queues.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was the highest, extra tokens need to be issued to compensate for all missing tokens that were not borrowed from parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]<br />
<br />
==Bucket Size in action==<br />
<br />
Lets have a simple setup where all traffic from and to one IP address is marked with a packet-mark:<br />
<br />
<pre><br />
/ip firewall mangle<br />
add chain=forward action=mark-connection connection-mark=no-mark src-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-connection connection-mark=no-mark dst-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-packet connection-mark=pc1_conn new-packet-mark=pc1_traffic<br />
</pre><br />
<br />
===Default Queue Bucket===<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M<br />
</pre><br />
<br />
In this case bucket-size=0.1, so bucket-capacity= 0.1 x 10M = 1M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 1Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
===Large Queue Bucket===<br />
<br />
Lets try to apply same logic to situation when bucket-size is at its maximal value:<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 100Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
So you can have:<br />
* 20Mbps transfer speed for 10s<br />
* 60Mbps transfer burst for 2s<br />
* 1Gbps transfer burst for ~100ms<br />
<br />
So as you can see bucket permits certain burstiness of the traffic that passes the queue.<br />
So behavior is similar to our burst feature, but lacks the upper limit of the burst.<br />
But this setback can be avoided when we utilize bucket size in queue structure:<br />
<br />
===Large Child Queue Bucket, Small Parent Queue Bucket ===<br />
<br />
<pre><br />
/queue tree<br />
add name=download_parent parent=Local max-limit=20M<br />
add name=download parent=download_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload_parent parent=Public max-limit=20M<br />
add name=upload parent=upload_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case: <br />
*parent queue bucket-size=0.1, bucket-capacity= 0.1 x 10M = 1M<br />
*child queue bucket-size=10, bucket-capacity= 10 x 10M = 100M<br />
<br />
So parent will run out of tokens much faster than child queue and, as child queue always borrows tokens from parent queue, whole system is restricted to token-rate of the parent queue - in this case to max-limit=20M, this rate will be sustained until child queue runs out of the tokens and will be restricted to its token-rate 10Mbps.<br />
<br />
So this way we can have up to 10 second burst at 20Mbps</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28391Manual:HTB-Token Bucket Algorithm2016-05-12T08:22:12Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.35+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the queue bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
In case of queue structure tokens used in a child queue are charged to parent queues also.<br />
in other words - children queues borrow tokens from their parent queues.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was the highest, extra tokens need to be issued to compensate for all missing tokens that were not borrowed from parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]<br />
<br />
==Bucket Size in action==<br />
<br />
Lets have a simple setup where all traffic from and to one IP address is marked with a packet-mark:<br />
<br />
<pre><br />
/ip firewall mangle<br />
add chain=forward action=mark-connection connection-mark=no-mark src-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-connection connection-mark=no-mark dst-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-packet connection-mark=pc1_conn new-packet-mark=pc1_traffic<br />
</pre><br />
<br />
===Default Queue Bucket===<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M<br />
</pre><br />
<br />
In this case bucket-size=0.1, so bucket-capacity= 0.1 x 10M = 1M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 1Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
===Large Queue Bucket===<br />
<br />
Lets try to apply same logic to situation when bucket-size is at its maximal value:<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 100Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
So you can have:<br />
* 20Mbps transfer speed for 10s<br />
* 60Mbps transfer burst for 2s<br />
* 1Gbps transfer burst for ~100ms<br />
<br />
So as you can see bucket permits certain burstiness of the traffic that passes the queue.<br />
So behavior is similar to our burst feature, but lacks the upper limit of the burst.<br />
But this setback can be avoided when we utilize bucket size in queue structure:<br />
<br />
===Large Child Queue Bucket, Small Parent Queue Bucket ===<br />
<br />
<pre><br />
/queue tree<br />
add name=download_parent parent=Local max-limit=20M<br />
add name=download parent=download_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload_parent parent=Public max-limit=20M<br />
add name=upload parent=upload_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case: <br />
*parent queue bucket-size=0.1, bucket-capacity= 0.1 x 10M = 1M<br />
*child queue bucket-size=10, bucket-capacity= 10 x 10M = 100M<br />
<br />
So parent will run out of tokens much more faster than child queue and as child queue always borrows tokens from parent queue, whole system is restricted to token-rate of parent queue - in this case it is max-limit=20M, this rate will be sustained until child queue runs out of the tokens and will be restricted to its token-rate 10Mbps.<br />
<br />
So this way we can have up to 10 second burst at 20Mbps</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28390Manual:HTB-Token Bucket Algorithm2016-05-12T08:20:37Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.35+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the queue bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
In case of queue structure tokens used in a child queue are charged to parent queues also.<br />
in other words - children queues borrow tokens from their parent queues.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was the highest, extra tokens need to be issued to compensate for all missing tokens that were not issued by parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]<br />
<br />
==Bucket Size in action==<br />
<br />
Lets have a simple setup where all traffic from and to one IP address is marked with a packet-mark:<br />
<br />
<pre><br />
/ip firewall mangle<br />
add chain=forward action=mark-connection connection-mark=no-mark src-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-connection connection-mark=no-mark dst-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-packet connection-mark=pc1_conn new-packet-mark=pc1_traffic<br />
</pre><br />
<br />
===Default Queue Bucket===<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M<br />
</pre><br />
<br />
In this case bucket-size=0.1, so bucket-capacity= 0.1 x 10M = 1M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 1Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
===Large Queue Bucket===<br />
<br />
Lets try to apply same logic to situation when bucket-size is at its maximal value:<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 100Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
So you can have:<br />
* 20Mbps transfer speed for 10s<br />
* 60Mbps transfer burst for 2s<br />
* 1Gbps transfer burst for ~100ms<br />
<br />
So as you can see bucket permits certain burstiness of the traffic that passes the queue.<br />
So behavior is similar to our burst feature, but lacks the upper limit of the burst.<br />
But this setback can be avoided when we utilize bucket size in queue structure:<br />
<br />
===Large Child Queue Bucket, Small Parent Queue Bucket ===<br />
<br />
<pre><br />
/queue tree<br />
add name=download_parent parent=Local max-limit=20M<br />
add name=download parent=download_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload_parent parent=Public max-limit=20M<br />
add name=upload parent=upload_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case: <br />
*parent queue bucket-size=0.1, bucket-capacity= 0.1 x 10M = 1M<br />
*child queue bucket-size=10, bucket-capacity= 10 x 10M = 100M<br />
<br />
So parent will run out of tokens much more faster than child queue and as child queue always borrows tokens from parent queue, whole system is restricted to token-rate of parent queue - in this case it is max-limit=20M, this rate will be sustained until child queue runs out of the tokens and will be restricted to its token-rate 10Mbps.<br />
<br />
So this way we can have up to 10 second burst at 20Mbps</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28389Manual:HTB-Token Bucket Algorithm2016-05-12T08:10:22Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the queue bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
In case of queue structure tokens used in a child queue are charged to parent queues also.<br />
in other words - children queues borrow tokens from their parent queues.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was the highest, extra tokens need to be issued to compensate for all missing tokens that were not issued by parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]<br />
<br />
==Bucket Size in action==<br />
<br />
Lets have a simple setup where all traffic from and to one IP address is marked with a packet-mark:<br />
<br />
<pre><br />
/ip firewall mangle<br />
add chain=forward action=mark-connection connection-mark=no-mark src-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-connection connection-mark=no-mark dst-address=192.168.88.101 new-connection-mark=pc1_conn<br />
add chain=forward action=mark-packet connection-mark=pc1_conn new-packet-mark=pc1_traffic<br />
</pre><br />
<br />
===Default Queue Bucket===<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M<br />
</pre><br />
<br />
In this case bucket-size=0.1, so bucket-capacity= 0.1 x 10M = 1M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 1Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
===Large Queue Bucket===<br />
<br />
Lets try to apply same logic to situation when bucket-size is at its maximal value:<br />
<br />
<pre><br />
/queue tree<br />
add name=download parent=Local packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload parent=Public packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case bucket-size=10, so bucket-capacity= 10 x 10M = 100M<br />
<br />
So if bucket is full (client was not using full capacity of the queue for some time),<br />
next 100Mb of traffic can cross the queue at unrestricted speed.<br />
<br />
So you can have:<br />
* 20Mbps transfer speed for 10s<br />
* 60Mbps transfer burst for 2s<br />
* 1Gbps transfer burst for ~100ms<br />
<br />
So as you can see bucket permits certain burstiness of the traffic that passes the queue.<br />
So behavior is similar to our burst feature, but lacks the upper limit of the burst.<br />
But this setback can be avoided when we utilize bucket size in queue structure:<br />
<br />
===Large Child Queue Bucket, Small Parent Queue Bucket ===<br />
<br />
<pre><br />
/queue tree<br />
add name=download_parent parent=Local max-limit=20M<br />
add name=download parent=download_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
add name=upload_parent parent=Public max-limit=20M<br />
add name=upload parent=upload_parent packet-mark=PC1-traffic max-limit=10M bucket-size=10<br />
</pre><br />
<br />
In this case: <br />
*parent queue bucket-size=0.1, bucket-capacity= 0.1 x 10M = 1M<br />
*child queue bucket-size=10, bucket-capacity= 10 x 10M = 100M<br />
<br />
So parent will run out of tokens much more faster than child queue and as child queue always borrows tokens from parent queue, whole system is restricted to token-rate of parent queue - in this case it is max-limit=20M, this rate will be sustained until child queue runs out of the tokens and will be restricted to its token-rate 10Mbps.<br />
<br />
So this way we can have up to 10 second burst at 20Mbps</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28383Manual:HTB-Token Bucket Algorithm2016-05-11T13:15:13Z<p>Megis: /* Token rate selection (Black part of the diagram) */</p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was the highest, extra tokens need to be issued to compensate for all missing tokens that were not issued by parent queue.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28382Manual:HTB-Token Bucket Algorithm2016-05-11T13:13:19Z<p>Megis: /* Token rate selection (Black part of the diagram) */</p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was highest, extra tokens need to be issued to bypass parent queue '''max-limit''' limitation.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28381Manual:HTB-Token Bucket Algorithm2016-05-11T13:11:44Z<p>Megis: /* Token rate selection (Black part the diagram) */</p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was highest "Extra tokens" were issued to bypass parent queue '''max-limit''' limitation.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28376Manual:HTB-Token Bucket Algorithm2016-05-10T12:09:46Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of the diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of the diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part the diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was highest "Extra tokens" were issued to bypass parent queue '''max-limit''' limitation.<br />
<br />
==The Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28375Manual:HTB-Token Bucket Algorithm2016-05-10T12:07:35Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method is covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of Diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, represented in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value was hard-coded to "0.1".<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of Diagram)==<br />
<br />
Size of this packet queue, sequence, how packets are added to this queue, and when packets are discarded, is determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of Diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : guaranteed upload/download data rate to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was highest "Extra tokens" were issued to bypass parent queue '''max-limit''' limitation.<br />
<br />
==Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28374Manual:HTB-Token Bucket Algorithm2016-05-10T11:54:51Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method are covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of Diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, representing in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value ""0.1" that was impossible to change.<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of Diagram)==<br />
<br />
Size of this packet queue,sequence how packets are added to this queue, and when packets are discarded, are determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of Diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : normal upload/download data rate that is guaranteed to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target to reach {{{...|to reach what}}}<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate which can be reached while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - more info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was highest "Extra tokens" were issued to bypass parent queue '''max-limit''' limitation.<br />
<br />
==Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:HTB-Token_Bucket_Algorithm&diff=28373Manual:HTB-Token Bucket Algorithm2016-05-10T11:50:29Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.33+ }}<br />
<br />
==Overview==<br />
<br />
This part of the wiki will concentrate on "Token Bucket" part of '''Hierarchical Token Bucket'''(HTB) - an algorithm inside the single queue. <br />
"Hierarchical" part of '''Hierarchical Token Bucket'''(HTB) queuing method are covered here:<br />
http://wiki.mikrotik.com/wiki/Manual:HTB<br />
<br />
==Token Bucket algorithm (Red part of Diagram)==<br />
<br />
The Token Bucket algorithm is based on an analogy to a bucket where tokens, representing in bytes, are added at specific rate.<br />
The bucket itself has a specified capacity. <br />
<br />
Queue gets tokens from parent queue, at a rate determined by parent queue.<br />
<br />
If the bucket fills to capacity, newly arriving tokens are dropped <br />
<br />
'''Bucket capacity = bucket-size * max-limit ''' <br />
<br />
*'''bucket size''' (0..10, Default:0.1) - queue option added in RouterOS v6.35, before that it had value ""0.1" that was impossible to change.<br />
<br />
Before letting any packet pass through queue, the bucket is inspected to see if it contains sufficient tokens at that moment.<br />
<br />
If, yes, the appropriate number of tokens, are removed ("cashed in") and packet can pass the queue.<br />
<br />
If, no, packets stays in the beginning of packet waiting queue until the appropriate amount of tokens are available.<br />
<br />
==Packet queue (Blue part of Diagram)==<br />
<br />
Size of this packet queue,sequence how packets are added to this queue, and when packets are discarded, are determined by:<br />
*'''queue-type''' - http://wiki.mikrotik.com/wiki/Manual:Queue#Kinds<br />
*'''queue-size''' - http://wiki.mikrotik.com/wiki/Manual:Queue_Size<br />
<br />
<br />
==Token rate selection (Black part of Diagram)==<br />
<br />
Maximal token rate at any given time is equal to highest active of these values:<br />
<br />
* '''limit-at''' (''NUMBER/NUMBER'') : normal upload/download data rate that is guaranteed to a target <br />
* '''max-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate that is allowed for a target to reach {{{...|to reach what}}}<br />
* '''burst-limit''' (''NUMBER/NUMBER'') : maximal upload/download data rate which can be reached while the burst is active<br />
<br />
'''burst-limit''' is active only when burst is in allowed state - mere info here: http://wiki.mikrotik.com/index.php?title=Manual:Queues_-_Burst<br />
<br />
In case '''limit-at''' was highest "Extra tokens" are issued to bypass parent queue '''max-limit''' limitation.<br />
<br />
==Diagram==<br />
<br />
[[File:bucket_size.png|800px]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Product_Naming&diff=28091Manual:Product Naming2016-02-01T08:54:06Z<p>Megis: /* Enclosure type */</p>
<hr />
<div>==Naming details for RouterBOARD products==<br />
<br />
RouterBOARD (short version RB)<br />
<br />
<code><board name> <board features>-<built-in wireless> <wireless card features>-<connector type><br />-<enclosure type></code><br />
<br />
===Board Name===<br />
<br />
Currently there can be three types of board names:<br />
<br />
* '''3-digit number'''<br />
** 1st digit stands for series<br />
** 2nd digit for indicating number of potential wired interfaces (Ethernet, SFP, SFP+)<br />
** 3rd digit for indicating number of potential wireless interfaces (built-in and mPCI and mPCIe slots)<br />
<br />
* '''Word''' - currently used names are: '''OmniTIK, Groove, SXT, SEXTANT, Metal'''. If board has fundamental changes in hardware (such as completely different CPU) revision version will be added in the end<br />
<br />
* '''Exceptional naming''' - 600, 800, 1000, 1100, 1200, 2011 boards are standalone representatives of the series or have more than 9 wired interfaces, so name was simplified to full hundreds or development year.<br />
<br />
<br />
===Board Features===<br />
<br />
Board features follows immediately after board name section (no spaces or dashes), except when board name is a word, then board features are separated by space.<br />
<br />
<br />
Currently used features (listed in order they are used):<br />
* '''U''' - USB<br />
* '''P''' - power injection with controller<br />
* '''i''' - single port power injector without controller<br />
* '''A''' - more memory (and usually higher license level)<br />
* '''H''' - more powerful CPU<br />
* '''G''' - Gigabit (may includes "U","A","H", if not used with "L")<br />
* '''L''' - light edition <br />
* '''S''' - SFP port (legacy usage - SwitchOS devices)<br />
* '''e''' - PCIe interaface extention card<br />
* '''x<N>''' - where N is number of CPU cores ( x2, x16, x36 etc)<br />
* '''R''' - MiniPCI or MINIPCIe slot<br />
<br />
===Built-in wireless details===<br />
<br />
If board has built-in wireless, then all its features are represented in following format:<br />
<br />
<code><band><power_per_chain><protocol><number_of_chains></code><br />
<br />
* '''band'''<br />
** '''5''' - 5Ghz<br />
** '''2''' - 2.4Ghz<br />
** '''52''' - dual band 5Ghz and 2.4Ghz<br />
<br />
* '''power per chain'''<br />
** (not used) - "Normal" - <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g<br />
** '''H''' - "High" - 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g<br />
** '''HP''' - "High Power" - 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g<br />
** '''SHP''' - "Super High Power" - 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g<br />
<br />
* '''protocol'''<br />
** (not used) - for cards with only 802.11a/b/g support<br />
** '''n''' - for cards with 802.11n support<br />
** '''ac''' - for cards with 802.11ac support<br />
<br />
* '''number_of_chains'''<br />
** (not used) - single chain<br />
** '''D''' - dual chain<br />
** '''T''' - triple chain<br />
<br />
<br />
* '''connector type'''<br />
** (not used) - only one connector option on the model<br />
** '''MMCX''' - MMCX connector type<br />
** '''u.FL''' - u.FL connector type<br />
<br />
<br />
===Enclosure type===<br />
<br />
* (not used) - main type of enclosure for a product<br />
* '''BU''' - board unit (no enclosure) - for situation when board-only option is required, but main product already comes in the case<br />
* '''RM''' - rack-mount enclosure<br />
* '''IN''' - indoor enclosure<br />
* '''EM''' - extended memory<br />
* '''LM''' - light memory<br />
* '''BE''' - black edition case<br />
* '''TC''' - Tower (vertical) case<br />
* '''OUT''' - outdoor enclosure<br />
<br />
===More Specific types '''OUT''' enclosures are:===<br />
<br />
* '''SA''' - sector antenna enclosure (for SXT)<br />
* '''HG''' - high gain antenna enclosure (for SXT)<br />
* '''BB''' - Basebox enclosure (for RB911)<br />
* '''NB''' - NetBox? enclosure (for RB911)<br />
* '''NM''' - NetMetal? enclosure (for RB911)<br />
* '''QRT''' - QRT enclosure (for RB911)<br />
* '''SX''' - Sextant enclosure (for RB911,RB711)<br />
* '''PB''' - PowerBOX enclosure (for RB750P, RB950P)<br />
<br />
===Example===<br />
<br />
Lets decode [http://routerboard.com/RB912UAG-5HPnD RB912UAG-5HPnD] naming<br />
<br />
* RB (RouterBOARD)<br />
* 912 - 9th series board with 1 wired (ethernet) interface and two wireless interfaces (built-in and miniPCIe)<br />
* UAG - has USB port, more memory and gigabit ethernet port<br />
* 5HPnD - has built in 5GHz high power dual chain wireless card with 802.11n support.<br />
<br />
==CloudCoreRouter naming details==<br />
<br />
CloudCoreRouter (short version CCR) naming consists of:<br />
<br />
<code><4 digit number>-<list of ports>-<enclosure type></code><br />
<br />
* '''4 digit number'''<br />
**1st digit stands for series<br />
**2nd (reserved)<br />
**3rd-4th digit indicate number of total CPU cores on the device<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
==CloudRouterSwitch naming details==<br />
<br />
CloudRouterSwitch (short version CRS) naming consists of:<br />
<br />
<code><3 digit number>-<list of ports>-<built-in wireless card>-<enclosure type></code><br />
<br />
* '''3 digit number'''<br />
**1st digit stands for series<br />
**2nd-3rd digit - total number of wired interfaces (Ethernet, SFP, SFP+)<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''built-in wireless card''' - same as for [[#Built-in_wireless_details | RouterBOARD products]].<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category: Routerboard|Naming]]<br />
[[Category: Manual|Naming]]<br />
[[Category:Basic|Naming]]<br />
[[Category:Hardware|Naming]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Product_Naming&diff=28090Manual:Product Naming2016-02-01T08:51:35Z<p>Megis: /* Enclosure type */</p>
<hr />
<div>==Naming details for RouterBOARD products==<br />
<br />
RouterBOARD (short version RB)<br />
<br />
<code><board name> <board features>-<built-in wireless> <wireless card features>-<connector type><br />-<enclosure type></code><br />
<br />
===Board Name===<br />
<br />
Currently there can be three types of board names:<br />
<br />
* '''3-digit number'''<br />
** 1st digit stands for series<br />
** 2nd digit for indicating number of potential wired interfaces (Ethernet, SFP, SFP+)<br />
** 3rd digit for indicating number of potential wireless interfaces (built-in and mPCI and mPCIe slots)<br />
<br />
* '''Word''' - currently used names are: '''OmniTIK, Groove, SXT, SEXTANT, Metal'''. If board has fundamental changes in hardware (such as completely different CPU) revision version will be added in the end<br />
<br />
* '''Exceptional naming''' - 600, 800, 1000, 1100, 1200, 2011 boards are standalone representatives of the series or have more than 9 wired interfaces, so name was simplified to full hundreds or development year.<br />
<br />
<br />
===Board Features===<br />
<br />
Board features follows immediately after board name section (no spaces or dashes), except when board name is a word, then board features are separated by space.<br />
<br />
<br />
Currently used features (listed in order they are used):<br />
* '''U''' - USB<br />
* '''P''' - power injection with controller<br />
* '''i''' - single port power injector without controller<br />
* '''A''' - more memory (and usually higher license level)<br />
* '''H''' - more powerful CPU<br />
* '''G''' - Gigabit (may includes "U","A","H", if not used with "L")<br />
* '''L''' - light edition <br />
* '''S''' - SFP port (legacy usage - SwitchOS devices)<br />
* '''e''' - PCIe interaface extention card<br />
* '''x<N>''' - where N is number of CPU cores ( x2, x16, x36 etc)<br />
* '''R''' - MiniPCI or MINIPCIe slot<br />
<br />
===Built-in wireless details===<br />
<br />
If board has built-in wireless, then all its features are represented in following format:<br />
<br />
<code><band><power_per_chain><protocol><number_of_chains></code><br />
<br />
* '''band'''<br />
** '''5''' - 5Ghz<br />
** '''2''' - 2.4Ghz<br />
** '''52''' - dual band 5Ghz and 2.4Ghz<br />
<br />
* '''power per chain'''<br />
** (not used) - "Normal" - <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g<br />
** '''H''' - "High" - 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g<br />
** '''HP''' - "High Power" - 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g<br />
** '''SHP''' - "Super High Power" - 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g<br />
<br />
* '''protocol'''<br />
** (not used) - for cards with only 802.11a/b/g support<br />
** '''n''' - for cards with 802.11n support<br />
** '''ac''' - for cards with 802.11ac support<br />
<br />
* '''number_of_chains'''<br />
** (not used) - single chain<br />
** '''D''' - dual chain<br />
** '''T''' - triple chain<br />
<br />
<br />
* '''connector type'''<br />
** (not used) - only one connector option on the model<br />
** '''MMCX''' - MMCX connector type<br />
** '''u.FL''' - u.FL connector type<br />
<br />
<br />
===Enclosure type===<br />
<br />
* (not used) - main type of enclosure for a product<br />
* '''BU''' - board unit (no enclosure) - for situation when board-only option is required, but main product already comes in the case<br />
* '''RM''' - rack-mount enclosure<br />
* '''IN''' - indoor enclosure<br />
* '''OUT''' - outdoor enclosure<br />
* '''SA''' - sector antenna enclosure<br />
* '''HG''' - high gain antenna enclosure<br />
* '''EM''' - extended memory<br />
* '''LM''' - light memory<br />
* '''BE''' - black edition case<br />
* '''TC''' - Tower (vertical) case<br />
<br />
===Example===<br />
<br />
Lets decode [http://routerboard.com/RB912UAG-5HPnD RB912UAG-5HPnD] naming<br />
<br />
* RB (RouterBOARD)<br />
* 912 - 9th series board with 1 wired (ethernet) interface and two wireless interfaces (built-in and miniPCIe)<br />
* UAG - has USB port, more memory and gigabit ethernet port<br />
* 5HPnD - has built in 5GHz high power dual chain wireless card with 802.11n support.<br />
<br />
==CloudCoreRouter naming details==<br />
<br />
CloudCoreRouter (short version CCR) naming consists of:<br />
<br />
<code><4 digit number>-<list of ports>-<enclosure type></code><br />
<br />
* '''4 digit number'''<br />
**1st digit stands for series<br />
**2nd (reserved)<br />
**3rd-4th digit indicate number of total CPU cores on the device<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
==CloudRouterSwitch naming details==<br />
<br />
CloudRouterSwitch (short version CRS) naming consists of:<br />
<br />
<code><3 digit number>-<list of ports>-<built-in wireless card>-<enclosure type></code><br />
<br />
* '''3 digit number'''<br />
**1st digit stands for series<br />
**2nd-3rd digit - total number of wired interfaces (Ethernet, SFP, SFP+)<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''built-in wireless card''' - same as for [[#Built-in_wireless_details | RouterBOARD products]].<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category: Routerboard|Naming]]<br />
[[Category: Manual|Naming]]<br />
[[Category:Basic|Naming]]<br />
[[Category:Hardware|Naming]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Product_Naming&diff=28089Manual:Product Naming2016-02-01T08:50:26Z<p>Megis: /* Board Features */</p>
<hr />
<div>==Naming details for RouterBOARD products==<br />
<br />
RouterBOARD (short version RB)<br />
<br />
<code><board name> <board features>-<built-in wireless> <wireless card features>-<connector type><br />-<enclosure type></code><br />
<br />
===Board Name===<br />
<br />
Currently there can be three types of board names:<br />
<br />
* '''3-digit number'''<br />
** 1st digit stands for series<br />
** 2nd digit for indicating number of potential wired interfaces (Ethernet, SFP, SFP+)<br />
** 3rd digit for indicating number of potential wireless interfaces (built-in and mPCI and mPCIe slots)<br />
<br />
* '''Word''' - currently used names are: '''OmniTIK, Groove, SXT, SEXTANT, Metal'''. If board has fundamental changes in hardware (such as completely different CPU) revision version will be added in the end<br />
<br />
* '''Exceptional naming''' - 600, 800, 1000, 1100, 1200, 2011 boards are standalone representatives of the series or have more than 9 wired interfaces, so name was simplified to full hundreds or development year.<br />
<br />
<br />
===Board Features===<br />
<br />
Board features follows immediately after board name section (no spaces or dashes), except when board name is a word, then board features are separated by space.<br />
<br />
<br />
Currently used features (listed in order they are used):<br />
* '''U''' - USB<br />
* '''P''' - power injection with controller<br />
* '''i''' - single port power injector without controller<br />
* '''A''' - more memory (and usually higher license level)<br />
* '''H''' - more powerful CPU<br />
* '''G''' - Gigabit (may includes "U","A","H", if not used with "L")<br />
* '''L''' - light edition <br />
* '''S''' - SFP port (legacy usage - SwitchOS devices)<br />
* '''e''' - PCIe interaface extention card<br />
* '''x<N>''' - where N is number of CPU cores ( x2, x16, x36 etc)<br />
* '''R''' - MiniPCI or MINIPCIe slot<br />
<br />
===Built-in wireless details===<br />
<br />
If board has built-in wireless, then all its features are represented in following format:<br />
<br />
<code><band><power_per_chain><protocol><number_of_chains></code><br />
<br />
* '''band'''<br />
** '''5''' - 5Ghz<br />
** '''2''' - 2.4Ghz<br />
** '''52''' - dual band 5Ghz and 2.4Ghz<br />
<br />
* '''power per chain'''<br />
** (not used) - "Normal" - <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g<br />
** '''H''' - "High" - 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g<br />
** '''HP''' - "High Power" - 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g<br />
** '''SHP''' - "Super High Power" - 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g<br />
<br />
* '''protocol'''<br />
** (not used) - for cards with only 802.11a/b/g support<br />
** '''n''' - for cards with 802.11n support<br />
** '''ac''' - for cards with 802.11ac support<br />
<br />
* '''number_of_chains'''<br />
** (not used) - single chain<br />
** '''D''' - dual chain<br />
** '''T''' - triple chain<br />
<br />
<br />
* '''connector type'''<br />
** (not used) - only one connector option on the model<br />
** '''MMCX''' - MMCX connector type<br />
** '''u.FL''' - u.FL connector type<br />
<br />
<br />
===Enclosure type===<br />
<br />
* (not used) - main type of enclosure for a product<br />
* '''BU''' - board unit (no enclosure) - for situation when board-only option is required, but main product already comes in the case<br />
* '''RM''' - rack-mount enclosure<br />
* '''IN''' - indoor enclosure<br />
* '''OUT''' - outdoor enclosure<br />
* '''SA''' - sector antenna enclosure<br />
* '''HG''' - high gain antenna enclosure<br />
* '''EM''' - extended memory<br />
<br />
<br />
===Example===<br />
<br />
Lets decode [http://routerboard.com/RB912UAG-5HPnD RB912UAG-5HPnD] naming<br />
<br />
* RB (RouterBOARD)<br />
* 912 - 9th series board with 1 wired (ethernet) interface and two wireless interfaces (built-in and miniPCIe)<br />
* UAG - has USB port, more memory and gigabit ethernet port<br />
* 5HPnD - has built in 5GHz high power dual chain wireless card with 802.11n support.<br />
<br />
==CloudCoreRouter naming details==<br />
<br />
CloudCoreRouter (short version CCR) naming consists of:<br />
<br />
<code><4 digit number>-<list of ports>-<enclosure type></code><br />
<br />
* '''4 digit number'''<br />
**1st digit stands for series<br />
**2nd (reserved)<br />
**3rd-4th digit indicate number of total CPU cores on the device<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
==CloudRouterSwitch naming details==<br />
<br />
CloudRouterSwitch (short version CRS) naming consists of:<br />
<br />
<code><3 digit number>-<list of ports>-<built-in wireless card>-<enclosure type></code><br />
<br />
* '''3 digit number'''<br />
**1st digit stands for series<br />
**2nd-3rd digit - total number of wired interfaces (Ethernet, SFP, SFP+)<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''built-in wireless card''' - same as for [[#Built-in_wireless_details | RouterBOARD products]].<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category: Routerboard|Naming]]<br />
[[Category: Manual|Naming]]<br />
[[Category:Basic|Naming]]<br />
[[Category:Hardware|Naming]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Fast_Path&diff=27380Manual:Fast Path2015-07-30T06:28:20Z<p>Megis: </p>
<hr />
<div>{{Versions|v6.0rc2 +}}<br />
<br />
__TOC__<br />
<br />
==Summary==<br />
<br />
Fast path allows to forward packets without additional processing in the Linux kernel. It improves forwarding speeds significantly.<br />
<br />
For fast path to work, interface support and specific configuration conditions are required.<br />
<br />
==List of devices with FastPath support==<br />
<br />
Interface FastPath support can be checked by doing "/interface print detail" and seeing fast-path property value.<br />
<br />
<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="300">Interfaces</th><br />
</tr><br />
<tr><br />
<td ><b>RB6xx series</b></td><br />
<td >ether1,2</td><br />
</tr><br />
<tr><br />
<td ><b>RB7xx series</b></td><br />
<td >all ethernets</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >ether1,2</td><br />
</tr><br />
<tr><br />
<td ><b>RB9xx series</b></td><br />
<td >all ethernets</td><br />
</tr><br />
<tr><br />
<td ><b>RB1000</b></td><br />
<td >all ethernets</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100 series</b></td><br />
<td >ether1-10,11</td><br />
</tr><br />
<tr><br />
<td ><b>RB2011 series</b></td><br />
<td >all ethernets and sfp</td><br />
</tr><br />
<tr><br />
<td ><b>CCR series routers</b></td><br />
<td >all ethernets and sfps</td><br />
</tr><br />
<tr><br />
<td ><b>All devices</b></td><br />
<td >wireless interfaces, if wireless-fp or wireless-cm2 package used</td><br />
</tr><br />
<tr><br />
<td ></td><br />
<td >bridge interfaces (since 6.29)</td><br />
</tr><br />
</table><br />
<br />
==FastPath Handlers==<br />
<br />
Currently RouterOS has following fast path handlers:<br />
<br />
* ipv4<br />
* ipv4 fasttrack<br />
* traffic generator<br />
* mpls<br />
* bridge<br />
<br />
{{ Note | Packet can be forwarded by fast path handler only if at least source interface support fast path. For complete fast path forwarding destination interface support is also required. See the [[#List_of_RouterBoards_with_FastPath_support | list]] of supported interfaces.}}<br />
<br />
=== IPv4 handler ===<br />
<br />
IPv4 fast path is automatically used if following conditions are met:<br />
<br />
* [[M:IP/Firewall | firewal rules]] are not configured;<br />
* Traffic flow is disabled <code>/ip traffic-flow enabled=no</code>;<br />
* Simple and [[Manual:Queue| queue]] trees with parent=global are not configured;<br />
* no [[M:Interface/HWMPplus | mesh]], [[M:Metarouter | metarouter]] interface configuration;<br />
* [[M:Tools/Packet_Sniffer | sniffer]], [[M:Troubleshooting_tools#Torch_.28.2Ftool_torch.29 | torch]] and [[M:Tools/Traffic_Generator | traffic generator]] is not running;<br />
* connection tracking is not active;<br />
* ip accounting is disabled (/ip accounting enabled=no);<br />
* VRFs are not set (/ip route vrf is empty);<br />
* Hotspot is not used (/ip hostspot has no interfaces);<br />
* IpSec policies are not configured (ROS v6.8);<br />
* no active mac-ping, mac-telnet or mac-winbox sessions;<br />
* /tool mac-scan is not actively used;<br />
* /tool ip-scan is not actively used;<br />
<br />
<code>/ip firewall connection tracking set enabled</code> parameter has new <var>auto</var> value Which means that connection tracking is disabled by default until firewall rules are added.<br />
<br />
=== IPv4 FastTrack handler===<br />
<br />
IPv4 FastTrack handler is automatically used for marked connections. Use firewall action "fasttrack-connection" to mark connections for fasttrack. Currently only TCP and UDP connections can be actually fasttracked (even though any connection can be marked for fasttrack). IPv4 FastTrack handler supports NAT (SNAT, DNAT or both).<br />
<br />
Note that not all packets in a connection can be fasttracked, so it is likely to see some packets going through slow path even though connection is marked for fasttrack. Fasttracked packets bypass firewall, simple queues, queue tree with parent=global, ip traffic-flow, ip accounting, ipsec, hotspot universal client, vrf assignment, so it is up to administrator to make sure fasttrack does not interfere with other configuration;<br />
<br />
IPv4 FastTrack is active if following conditions are met:<br />
<br />
* no [[M:Interface/HWMPplus | mesh]], [[M:Metarouter | metarouter]] interface configuration;<br />
* [[M:Tools/Packet_Sniffer | sniffer]], [[M:Troubleshooting_tools#Torch_.28.2Ftool_torch.29 | torch]] and [[M:Tools/Traffic_Generator | traffic generator]] is not running;<br />
* no active mac-ping, mac-telnet or mac-winbox sessions;<br />
* /tool mac-scan is not actively used;<br />
* /tool ip-scan is not actively used;<br />
<br />
For example, in home routers with factory default configuration, you could Fasttrack all LAN traffic with this one rule placed at the top of the Firewall Filter:<br />
<br />
/ip firewall filter add chain=forward action=fasttrack-connection connection-state=established,related<br />
<br />
Note, that this will break any filtering and Queues you apply for LAN traffic, you will have to mark traffic first, if you want to only fasttrack specific traffic.<br />
<br />
This is how a default configuration looks with fastpath rule added on top (and auto-added dummy rule above it):<br />
<br />
[[File:fasttrack.png]]<br />
<br />
===Traffic Generator handler===<br />
<br />
Traffic Generator fast path is automatically used for interfaces that support this feature.<br />
<br />
===MPLS handler===<br />
<br />
MPLS fast path is automatically used for interfaces that support this feature.<br />
<br />
Currently MPLS fast-path applies only to MPLS switched traffic (frames that enter router as MPLS and must leave router as MPLS) - MPLS ingress and egress (including VPLS tunnel endpoints that do VPLS encap/decap) will operate as before.<br />
<br />
<br />
===Bridge handler===<br />
<br />
Bridge fast path is automatically used if following conditions are met:<br />
<br />
* no [[M:Interface/Bridge#Bridge_Firewall | bridge firewall]] rules (<code>/interface bridge filter, /interface bridge nat</code>) are configured,<br />
* <code>/interface bridge settings use-ip-firwall=no</code>,<br />
* destination interface queue is set to [[Manual:Queue#Queue_Types | only-hw-queue]],<br />
* no [[M:Interface/HWMPplus | mesh]], [[M:Metarouter | metarouter]] interface configuration,<br />
* [[M:Tools/Packet_Sniffer | sniffer]], [[M:Troubleshooting_tools#Torch_.28.2Ftool_torch.29 | torch]] and [[M:Tools/Traffic_Generator | traffic generator]] is not running,<br />
* if wireless is configured, then wireless-fp or wireless-cm2 package must be used in order to use FastPath<br />
<br />
{{Note | Currently VLAN, PPP and Bonding interfaces does not support FastPath}}<br />
<br />
{{Note | Starting from v6.1 added VRRP interface no longer disables fast path globally.<br />
Ipv4 and bridge fast path handlers will not work only if source interface is vrrp slave interface.}}<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|Fast]]<br />
[[Category:Routerboard|Fast]]<br />
[[Category:Hardware|Fast]]<br />
[[Category:Interface|Fast]]<br />
[[Category:Case Studies|Fast]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27236Manual:Packet Flow v62015-05-28T07:25:19Z<p>Megis: /* Examples */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow Diagram|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27235Manual:Packet Flow v62015-05-28T07:24:56Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow Diagram|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27234Manual:Packet Flow v62015-05-28T07:24:00Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow Diagram|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27233Manual:Packet Flow v62015-05-27T08:10:55Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow Diagram|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27232Manual:Packet Flow v62015-05-27T08:10:22Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow Diagram|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27231Manual:Packet Flow v62015-05-27T07:57:42Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow Diagram|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27230Manual:Packet Flow v62015-05-27T07:57:13Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27229Manual:Packet Flow v62015-05-27T07:42:47Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow General|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Packet_Flow_v6&diff=27228Manual:Packet Flow v62015-05-27T07:42:25Z<p>Megis: /* Diagram */</p>
<hr />
<div>{{Versions| v6+}}<br />
__TOC__<br />
<br />
<br />
==Overview==<br />
<br />
<br />
<br />
==Diagram==<br />
<br />
[[Image:PacketFlowDiagram_v6_a.svg|Packet Flow General|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_b.svg|Packet Flow Sections|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_c.svg|Packet Flow Chains|700px|center]]<br />
<br />
==Examples==<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_a.gif|Example 1|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_b.gif|Example 2|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_c.gif|Example 3|700px|center]]<br />
<br />
<br />
[[Image:PacketFlowDiagram_v6_examples_d.gif|Example 4|700px|center]]<br />
<br />
===Ipsec Encryption/Decryption===<br />
<br />
[[Image:IpsecFlow.png|Example 5|700px|center]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual|P]]<br />
[[Category:IP|P]]<br />
[[Category:QoS|P]]<br />
[[Category:Case Studies|P]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Product_Naming&diff=25605Manual:Product Naming2013-07-12T12:29:03Z<p>Megis: </p>
<hr />
<div>==Naming details for RouterBOARD products==<br />
<br />
RouterBOARD (short version RB)<br />
<br />
<code><board name> <board features>-<build-in wireless> <wireless card features>-<connector type><br />-<enclosure type></code><br />
<br />
===Board Name===<br />
<br />
Currently there can be three types of board names:<br />
<br />
* '''3-digit number'''<br />
** 1st digit stands for series<br />
** 2nd digit for indicating number of potential wired interfaces (Ethernet, SFP, SFP+)<br />
** 3rd digit for indicating number of potential wireless interfaces (build-in and mPCI and mPCIe slots)<br />
<br />
* '''Word''' - currently used names are: '''OmniTIK, Groove, SXT, SEXTANT, Metal'''. If board has fundamental changes in hardware (such as completely different CPU) revision version will be added in the end<br />
<br />
* '''Exceptional naming''' - 600, 800, 1000, 1100, 1200, 2011 boards are standalone representatives of the series or have more than 9 wired interfaces, so name was simplified to full hundreds or development year.<br />
<br />
<br />
===Board Features===<br />
<br />
Board features follows immediately after board name section (no spaces or dashes), except when board name is a word, then board features are separated by space.<br />
<br />
<br />
Currently used features (listed in order they are used):<br />
* '''U''' - USB<br />
* '''P''' - power injection with controller<br />
* '''i''' - single port power injector without controller<br />
* '''A''' - more memory (and usually higher license level)<br />
* '''H''' - more powerful CPU<br />
* '''G''' - Gigabit (may includes "U","A","H", if not used with "L")<br />
* '''L''' - light edition <br />
* '''S''' - SFP port (legacy usage - SwitchOS devices)<br />
* '''e''' - PCIe interaface extention card<br />
* '''x<N>''' - where N is number of CPU cores ( x2, x16, x36 etc)<br />
<br />
<br />
===Built-in wireless details===<br />
<br />
If board has built-in wireless, then all its features are represented in following format:<br />
<br />
<code><band><power_per_chain><protocol><number_of_chains></code><br />
<br />
* '''band'''<br />
** '''5''' - 5Ghz<br />
** '''2''' - 2.4Ghz<br />
** '''52''' - dual band 5Ghz and 2.4Ghz<br />
<br />
* '''power per chain'''<br />
** (not used) - "Normal" - <23dBm at 6Mbps 802.11a; <24dBm at 6Mbps 802.11g<br />
** '''H''' - "High" - 23-24dBm at 6Mbps 802.11a; 24-27dBm at 6Mbps 802.11g<br />
** '''HP''' - "High Power" - 25-26dBm 6Mbps 802.11a; 28-29dBm at 6Mbps 802.11g<br />
** '''SHP''' - "Super High Power" - 27+dBm at 6Mbps 802.11a; 30+dBm at 6Mbps 802.11g<br />
<br />
* '''protocol'''<br />
** (not used) - for cards with only 802.11a/b/g support<br />
** '''n''' - for cards with 802.11n support<br />
** '''ac''' - for cards with 802.11ac support<br />
<br />
* '''number_of_chains'''<br />
** (not used) - single chain<br />
** '''D''' - dual chain<br />
** '''T''' - triple chain<br />
<br />
<br />
* '''connector type'''<br />
** (not used) - only one connector option on the model<br />
** '''MMCX''' - MMCX connector type<br />
** '''u.FL''' - u.FL connector type<br />
<br />
<br />
===Enclosure type===<br />
<br />
* (not used) - main type of enclosure for a product<br />
* '''BU''' - board unit (no enclosure) - for situation when board-only option is required, but main product already comes in the case<br />
* '''RM''' - rack-mount enclosure<br />
* '''IN''' - indoor enclosure<br />
* '''OUT''' - outdoor enclosure<br />
* '''SA''' - sector antenna enclosure<br />
* '''HG''' - high gain antenna enclosure<br />
* '''EM''' - extended memory<br />
<br />
<br />
===Example===<br />
<br />
Lets decode [http://routerboard.com/RB912UAG-5HPnD RB912UAG-5HPnD] naming<br />
<br />
* RB (RouterBOARD)<br />
* 912 - 9th series board with 1 wired (ethernet) interface and two wireless interfaces (built-in and miniPCIe)<br />
* UAG - has USB port, more memory and gigabit ethernet port<br />
* 5HPnD - has built in 5GHz high power dual chain wireless card with 802.11n support.<br />
<br />
==CloudCoreRouter naming details==<br />
<br />
CloudCoreRouter (short version CCR) naming consists of:<br />
<br />
<code><4 digit number>-<list of ports>-<enclosure type></code><br />
<br />
* '''4 digit number'''<br />
**1st digit stands for series<br />
**2nd (reserved)<br />
**3rd-4th digit indicate number of total CPU cores on the device<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
==CloudRouterSwitch naming details==<br />
<br />
CloudRouterSwitch (short version CRS) naming consists of:<br />
<br />
<code><3 digit number>-<list of ports>-<build-in wireless card>-<enclosure type></code><br />
<br />
* '''3 digit number'''<br />
**1st digit stands for series<br />
**2nd-3rd digit - total number of wired interfaces (Ethernet, SFP, SFP+)<br />
<br />
* '''list of ports'''<br />
**-<n>G - number of Gigabit Ethernet ports<br />
**-<n>S - number of SFP ports<br />
**-<n>S+ - number of SFP+ ports<br />
<br />
* '''build-in wireless card''' - same as for [[#Built-in_wireless_details | RouterBOARD products]].<br />
<br />
* '''enclosure type''' - same as for [[#Enclosure_type | RouterBOARD products]].<br />
<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category: Routerboard|Naming]]<br />
[[Category: Manual|Naming]]<br />
[[Category:Basic|Naming]]<br />
[[Category:Hardware|Naming]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Supported_Hardware&diff=23646Supported Hardware2012-05-17T12:46:16Z<p>Megis: /* SFP modules */</p>
<hr />
<div>''This page should be edited by the user community to reflect their tested hardware and version used.''<br />
<br />
See also: [http://wiki.mikrotik.com/wiki/Manual:Driver_list Device driver list] in manual <br />
<br />
=='''Motherboards'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Vendor !! Model !! ROS version !! Result<br />
|-<br />
|-<br />
! Asrock || Intel 82801G chipset <br />
| 3.0-3.14 || Bad performance, locks up under heavy load, supports multi cpu, PATA not supported, integrated ethernet not recognized. Maybe it's just Asrock bad motherboard don't know if the problem is in intel 82801G chipset tested on 2 motherboards, never tested on 2.9.x <br />
|-<br />
! ASUS ||P8H67-V (Intel® H67(B3), 3xPCI, 4xPCI-E)<br />
| 5.XX || Don't work. "Kernel Panic". Mikrotik has not driver compatibility with this motherboard. <br />
|-<br />
! ASUS || P5B-Deluxe (Intel P965, 3xPCI, 3xPCI-E)<br />
| 3.13 || Works fine on Intel Core 2 Duo E6400. Not supported PATA controller. Both integrated Gigabit NIC (Marvell Yukon 88E8056 & 88E8001) works fine but only at 100Mbps.<br />
|-<br />
! ASUS || P5B-V (Intel P965, 3xPCI, 4xPCI-E)<br />
| 3.13 || Works fine on Intel Dual Core E2180. Not supported PATA controller. Integrated Gigabit NIC Marvell Yukon 88E8001 works fine but only at 100Mbps. Winbox via MAC = problem, disconnects after 3 seconds. Winbox via IP no problem. <br />
|-<br />
! ASUS || P5KC (Intel P35, 3x PCI, 3xPCI-E)<br />
| 3.10 || Not supported PATA controller (JMicron JMB363), ROS can boot from USB flash drive; internal ethernet not recognized.<br />
|-<br />
! ASUS || P5GC-MX/1333 (2x PCI)<br />
| 3.7 || Works great for pentium dual-core e2160, hdd pata and sata, 1,5gb ram dual channel mode, except the attansic l2 ethernet onboard card is not recognized.<br />
|-<br />
! ASUS || P5GC (6xPCI)<br />
| 2.9.39 || Ethernet recognized but not working<br />
|-<br />
! ASUS || P7P55D PRO<br />
| 4.5 || Works ok, PATA controller (JMicron JM363) and internal Ethernet successfully recognized.<br />
|-<br />
! ASUS || P6T SE<br />
| 4.0 || RouterOS boots and works with SATA disk set to 'IDE compatibility mode'.<br />
|-<br />
! ASUS || A7V133-C<br />
|3.0 beta 7 || Works fine<br />
|-<br />
! ASUS || A7V600-X<br />
|3.25 || Works fine<br />
|-<br />
! EPoX || EP-4VKMI<br />
| 3.16 - 3.24 || Works fine.<br />
|-<br />
! EPoX || 8RDA+ <br />
| 3.6 || Work fine including integrated ethernet<br />
|-<br />
! Intel || D815EGEW<br />
| 2.9.x || Excellent performance under 2.9. Not tested under v3. Onboard Ethernet Works perfectly.<br />
|-<br />
! Intel || D845GVSRL<br />
| 3.7, 3.1, 2.9<br />
|Very Stable, used for 4 years<br />
|-<br />
! Intel || D945GCCRL<br />
| 2.9.43 & 3.0 beta 5 || Ethernet & DoM not recognized<br />
|-<br />
! Intel || D945GCLF2<br />
| 3.23 || 4 core's, 2gb ram, 32gb ssd, no problems.<br />
|-<br />
! Intel || D945GCPE<br />
| 3.0 beta 9 || Work fine including integrated ethernet<br />
|-<br />
! Intel || D945GCNL<br />
| 3.11 || Works fine but integrated ethernet (just disable) goes up and down on reboots multi-cpu= yes. shared IRQ for PCI devices, decrease nic performace.<br />
|-<br />
! Intel || D945GNT<br />
| 2.9.45 <br />
|Works fine<br />
|-<br />
! Intel || DG33FB<br />
| 3.7 || Works fine, Ethernet but not working (IRQ 9), set in BIOS Security/XD Tegnology to disable<br />
|-<br />
! Intel || DG950<br />
| 2.9.42 || Ethernet not recognized<br />
|-<br />
! Intel || DG965SWH<br />
| 3.0 beta 9 || Works fine, but only with SATA not IDE<br />
|-<br />
! Intel || DH67BLB3<br />
| 5.14 || Works Great with i7-2600k processor<br />
|-<br />
! Intel || DP55WG<br />
| 4.6<br />
|multi-cpu smp works great, onboard NIC not supported by RouterOS 4.6 yet though, must use pci/pci express nics<br />
|-<br />
! Intel || DQ965GFEKR (D41676)<br />
| 3.7, 3.4 <br />
|Works fine on 3.7/3.4 if multi-cpu=no, BUT 3.5-3.7 fail to boot with E4600 processor and multi-cpu=yes<br />
|-<br />
! Intel || S3210SHLC<br />
| 4.2 || Boot from USB stick. Work fine for my PPPoE server. Up to 1300 users with summary 200Mbit traffic.<br />
|-<br />
! Intel || D945GZT-M<br />
| 3.0rc4 <br />
|Works fine<br />
|-<br />
! Chaintech || AADF950<br />
|3.0 beta 5<br />
|Works fine<br />
|-<br />
! Abit || KT7E<br />
|3.0 beta 7<br />
|Works fine<br />
|-<br />
! ECS || nForce3-A<br />
|3.6<br />
|Work fine including integrated ethernet<br />
|-<br />
! ECS || P4M800PRO-M478<br />
|2.9.43<br />
|No Apparent Problems, Disabled any unneeded devices in the BIOS<br />
|-<br />
! Abit || BE6<br />
| 2.9.43 || Works<br />
|-<br />
! VIA || EPIA-MII12000<br />
| 2.9.42 || Locks up under heavy load across wireless<br />
|-<br />
! Supermicro || 5015M-MR<br />
| 2.9.28 || Motherboard is PDSMi w dual core<br />
|-<br />
! Supermicro || PDSBM-LN2+<br />
| 2.9.51 & 3.16 || http://forum.mikrotik.com/viewtopic.php?f=1&t=28184<br />
|-<br />
! Supermicro || PDSMi-LN4+<br />
| 2.9.51, 3.13, 3.20 || Very stable even with dual-cores enabled. <br />
|-<br />
! Gigabyte || GA-41M-ES2L<br />
| 3.28 || Works fine; CPU Intel Core2 Dual 2.7GHz; 2XRB44GV <br />
|-<br />
! Gigabyte || GA-6BXS<br />
| 2.9.43 || Works fine<br />
|-<br />
! Gigabyte || GA-8I848P-G<br />
| 3.6 || Work fine including integrated ethernet<br />
|-<br />
! Gigabyte || GA-8ST667 rev. 3.0<br />
| 3.13 || Works fine; CPU Intel Celeron 2,4GHz; Chipset SiS 645DX; 5xPCI; <br />
|-<br />
! Gigabyte || GA-M720-US3 rev 1.0<br />
| 4.6 || Works fine (downvolted to 1.1V)<br />
|-<br />
! Gigabyte || GA-MA790GP-UD4H<br />
| 3.30 || Works fine<br />
|-<br />
! Gigabyte || K8-NS-ULTRA<br />
| 2.9.x-3.7 || Excelent work, including both onboard ethernet (100 and 1000 lan)<br />
|-<br />
! Gigabyte || GA-MA770-DS3 (rev. 2.0)<br />
| 3.10 || Works fine and extreme stable include onboard LAN, IDE DOM can load normally <br />
|-<br />
! || Chipset P35 (Tested Using Gigabyte GA-P35-DS3L & Abit IP35)<br />
| 3.7 || Work fine but only with SATA, not IDE (Include DOM), bellow v3.7 problem with SATA too<br />
|-<br />
! Microsoft || Virtual PC 2007<br />
| 3.7 || Installs and and tries to boot.<br />
|-<br />
! VMware || Workstation v6.0.3<br />
| 3.7 || Runs Wicked Fast! I have had up to 8 Ethernet interfaces running simultaneously.<br />
|-<br />
! VMware || ESXi v4<br />
| 3.30 || Select IDE type for virtual disk - works perfectly!<br />
|-<br />
! || Xen 3.2.1 on Intel C2Q<br />
| 4.x || Installs and runs fine on HVM bootloader using Intel VT technology. Even switches to RouterOS console from Dom0 shell. Ethernet interfaces work perfectly. '''Do not install xen/kvm RouterOS packages!'''<br />
|-<br />
! DFI || AD73 Pro (Chipset VIA KT266A/VT8233ACD)<br />
| 2.9.x-3.30 || Works fine. All 5 PCI's ocupied with 1 x LAN and 6 x R52H's (3 in RouterBoard11 and 3 in RouterBoard14!)<br />
|-<br />
! DFI || AK75-EC (Chipset VIA KT133A/686B)<br />
| 3.14-3.30 || Stable. All PCI's ocupied with LAN, miniPCI-PCI adapters fitted with R5H/R52H's and XR5's<br />
|-<br />
! Fujitsu Siemens || Primergy RX100S5<br />
| 3.1, 3.7, 3.22 || Can Install from Netinstall with RAID (LSI) Controller enable. Can't install from CD and Netinstall with only SATA or PATA mode. <font color=red><b>But NOT RUN</b></font><br />
|-<br />
! MSI || 785GM-E51<br />
| 4.11 || Works fine, booted from USB stick, integrated LAN working<br />
|-<br />
|}<br />
<br />
=='''Ethernet chipsets'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Vendor !! Model !! ROS version !! Result<br />
|-<br />
! 3Com || 3c905B Cyclone 100BaseTX<br />
| 2.9.51 || Works! Extremely reliable, doesn't fully support tagged vlans<br />
|-<br />
! 3Com || 3cSOHO100-TX [Hurricane] (rev: 48)<br />
| 3.14rc1 || Works<br />
|-<br />
! 3Com || 3c905C-TX/TX-M [Tornado] (rev: 120) <br />
| 2.9.51 || Works! Extremely reliable, doesn't fully support tagged vlans<br />
|-<br />
! 3Com || 3c905C-TX/TX-M [Tornado] (rev: 116) <br />
| 2.9.51 || Works! Extremely reliable, doesn't fully support tagged vlans<br />
|-<br />
! 3Com || 3c905B-FX Fast Etherlink XL FX 100baseFx [Cyclone] (rev: 0)<br />
|2.9.43 || Works but no link in Winbox and no Graph in Dude !!!! <br />
|-<br />
! Adaptec || ANA-6944A/TX Quad 10/100MBit <br />
|>=3.20<br />
|Works<br />
|-<br />
! Compaq || NC3122 Fast Ethernet Server Adapter <br />
|3.30<br />
|recognized but not working<br />
|-<br />
! Intel || S82557 10/100MBit <br />
|2.9.43<br />
|works<br />
|-<br />
! Intel || PWLA8391GT PRO1000/GT<br />
|3.7, 3.1, 2.9<br />
|Extremely Stable, used for years<br />
|-<br />
! Intel || PWLA8391GTL PRO1000/GT<br />
|3.4<br />
|Extremely Stable, used for years<br />
|-<br />
!Intel ||82575EB & 8257GB<br />
|3.15<br />
|Added support<br />
|-<br />
!Intel || 82576 Gigabit ET Quad port<br />
|4.5<br />
|Not recognized<br />
|-<br />
!Intel || 82576 Gigabit Dual Port (e1g42et)<br />
|5.8<br />
|Works<br />
|-<br />
!Intel || 82572EI (EXPI9300PTBLK)<br />
|4.5, 4.6<br />
|Works<br />
|-<br />
!Intel || 82572GI (EXPI9400PTBLK)<br />
|4.5, 5.14<br />
|Works<br />
|-<br />
! Intel || 82574L (EXPI9301CT)<br />
|5.14<br />
|Supported in ROS 5 / Works<br />
|-<br />
! Intel || 82571EB (EXPI9404PT) QUAD COPPER<br />
|4.6, 5.14<br />
|Works<br />
|-<br />
! Intel || S82557/S82555 10/100 Mbit TX<br />
| 2.9.50 / 3.16|| Works Stable! FCC ID:EJMNPDSPD035<br />
|-<br />
! Intel || PRO 1000 MT <br />
|2.9.51<br />
|Works<br />
|-<br />
! Intel || 82541GI/PI Gigabit Ethernet Controller (rev: 5)<br />
|2.9.49<br />
|Working but with high traffic (>100M) and many packets makes drops<br />
|-<br />
|-<br />
! Intel || 10Gbit Ethernet PCI Express <br />
| 3.17 || Works<br />
|-<br />
! Intel || 82557/8/9 Ethernet Pro 100 (rev: 5)/Dual ports(Two ports/2-port)/RJ-45"<br />
| 4.10 || Works, fine! <br />
|-<br />
! D-Link || DFE-528TX rev. E1<br />
|3.13<br />
| Works<br />
|-<br />
! D-Link || DFE-580TX 4-port <br />
|3.0 beta 5<br />
|Bad card, not recommended. Hangs router<br />
|-<br />
! D-Link || DFE-530/538TX <br />
|2.9.43 - 3.x<br />
|Works well, no apparent problems.<br />
|-<br />
!D-Link || DUB-E100 USB<br />
|3.18<br />
|added support, reported to be working<br />
|-<br />
!Marvell || 88E8001 Gigabit Ethernet Controller (rev: 20)<br />
|3.13<br />
|Works<br />
|-<br />
!Marvell || 88E8056<br />
|3.6<br />
|reported to be working with some BIOS setting enabled<br />
|-<br />
! DECchip || 21143 (ZYNX ZX410 4-port cPCI)<br />
|2.9.51<br />
|Working<br />
|-<br />
! Realtek || RTL-8169 Gigabit Ethernet x4 (rev: 16)<br />
|3.0-3.11<br />
|Working Extremely reliable, used 4 mounts<br />
|-<br />
! Realtek || RTL8111 (10/100/1000Mbit)<br />
|3.10<br />
|Seems to be working only in older RouterOS v3 releases, v3.10 and before. <br />
|-<br />
! Realtek || RTL8111C, RTL8111DL (10/100/1000Mbit)<br />
|4.6 - 4.11<br />
|Working<br />
|-<br />
! Realtek || RTL8139C+<br />
|3.14<br />
|Works<br />
|-<br />
! Realtek || RTL8139D<br />
|3.x<br />
|Some work, others don't. Check for yourself.<br />
|-<br />
! Realtek || RTL-8139/8139C/8139C+ (rev: 16)<br />
| 4.9 & 4.10 || Works, fine! <br />
|-<br />
! Realtek || RTL-8029(AS) (rev: 0)"<br />
| 4.9 & 4.10 || Works, fine! <br />
|-<br />
! ZNYX || ZX346Q<br />
|3.27<br />
|Works<br />
|-<br />
! VIA || VT6102 [Rhine-II] (rev: 67)"<br />
| 4.9 & 4.10 || Works, fine! <br />
|-<br />
<br />
|}<br />
<br />
=='''x86 Systems'''==<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! ROS version !! Result<br />
|-<br />
! Dell Optiplex GX1<br />
|2.9.x-3.0<br />
|Intel onboard/cpu 450-600Mhz, eth:3com, best for wirless stations; uptime over 200d, no problems at all.<br />
|-<br />
! Compaq Presario 2282<br />
|2.9.43<br />
|With 3c905 [Boomerang], no apparent problems<br />
|-<br />
! Dell GX100<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu<br />
|-<br />
! Dell GX240<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu, IDE HDD.<br />
|-<br />
! Dell GX260<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu, IDE HDD.<br />
|-<br />
! Dell GX270<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu. IDE HDD.<br />
|-<br />
! Dell GX280<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu, SATA HDD.<br />
|-<br />
! Dell Dimension XPS GEN 3<br />
| 2.9.x<br />
| Lan Onboard, 4 free pci, Intel cpu , SATA HDD ( Excellent Stability )<br />
|-<br />
! Dell Inspiron Desktop 518<br />
|2.9.x - 3.7<br />
|After netinsall stuck on "loading system"<br />
|-<br />
! Dell PowerEdge 860<br />
|3.x<br />
|1U Rackmount, 2x Broadcom Gigabit onboard, 1x Intel CPU (many options), 1 PCI/1 PCIe or 2 PCIe riser options, SATA HDD ONLY. (some issues with floppy netinstall)<br />
|-<br />
! Dell PowerEdge R200<br />
|>= 3.19 recommended<br />
|Severe stability and clock issues with non-current ROS. Works like a top on 3.19 though. Also, if using an SATA-to-CF converter, the license key for the CF card in an R200 will only transfer to other R200's without Mikrotik reissuing it. <br />
|-<br />
! Dell PowerEdge R210<br />
| 5.1 - 5.6<br />
|1U Rackmount. Half-depth (39cm) chassis. Dual port on-board Broadcom 5716 Gigabit Ethernet controllers. Single CPU on Intel 3420 Motherboard Chipset. Works OK and stable, once installed. Some issues with NetInstall - PXE boot works OK but install can't continue (says waiting for drivers...). Tested with Intel Gigabit ET Quad Port Server Adapter - works perfectly.<br />
|-<br />
! Dell PowerEdge R310<br />
| 5.0rc7<br />
|1U Rackmount. 2 x on-board Broadcom 5716 Gigabit Ethernet controllers. Single CPU on Intel 3420 Motherboard Chipset. Works OK and stable, once installed. Some issues with NetInstall - PXE boot works OK but install can't continue (says waiting for drivers...). Tested with Intel Gigabit ET Quad Port Server Adapter - works perfectly.<br />
|-<br />
! Dell PowerEdge 2950<br />
|3.x<br />
|2U Rackmount, Optional Redundant Power Supplies, 2x Broadcom Gigabit onboard, 2x Intel CPU (many options), 2- 8xPCIe & 1- 4xPCIe Standard (other risers available), SATA HDD ONLY, 2x internal USB - MUST SPECIAL ORDER WITHOUT RAID CONTROLLER. (some issues with floppy netinstall)}<br />
|-<br />
! HP Proliant DL380 G5<br />
|3.17<br />
|Works, but only if installed from CDROM (Netinstall to Windows mounted HDD causes issues)<br />
|-<br />
! Asus EEE PC 701<br />
|3.x<br />
|SFF Laptop, 1x10/100 ethernet (Not detected), Stock Wireless unsupported (AR5007E In Mini-PCIX slot), 630/900Mhz processor, 512MB RAM, 4GB SSD (Not detected), USB2.0 Bootable, SDHC Reader functions as a USB Stick<br />
|-<br />
! Dell PowerEdge SC1425<br />
|3.x<br />
|Rackmount, Intel Xeon 2.8 1MB 800FSB, 1024MB DDR2 PC3200 ECC, 2x Intel 82541GI Gigabit Ethernet, HD150gb SATA, USB works, very stable <br />
|-<br />
! Fujitsu Siemens Primergy RX100S5<br />
| 3.7, 3.22 || Can Install from Netinstall with RAID (LSI) Controller enable. Can't install from CD and Netinstall with only SATA or PATA mode. <font color=red><b>But NOT RUN</b></font><br />
|-<br />
! Toshiba Magnia SG20<br />
| 2.9.44 || CPU Celeron, VIA chipsets, onboard LAN Realtek and Intel, IDE HDD, PCMCIA tested with Orinoco Silver, miniPCI LT WinModem <b>not work</b><br />
|-<br />
! Advantech FWA-3800<br />
| 4.11, 4.17, 5.14 || CPU Intel Core2 Duo 2,93GHz, 2GB RAM DDR2, 6 x Intel 1Gbps PCIe NIC, 1U size, works good as a BGP router. If you have troubles with MT 5.x on it, try to reset BIOS (by battery remove).<br />
|-<br />
|}<br />
<br />
=='''Embedded Controllers'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! ROS version !! Result<br />
|-<br />
! WRAP.1E-2<br />
| 2.9.51, 3.7 || 3 Ethernet, 1 miniPCI, 128 MB - Working<br />
|-<br />
! WRAP.2E <br />
| 2.9.51, 3.7, 3.9, 3.10 || 1 Ethernet, 2 MiniPCI, 128 MB - Work fine<br />
|-<br />
! ALIX 2-2 <br />
| 2.9.48 || 2 Ethernet, 2 miniPCI - Working<br />
|-<br />
! Adlink cPCI-6770 Low Power Pentium III <br />
|2.9 and 3.0 || CompactPCI CPU Module - Working, excellent performance!<br />
|-<br />
! Advantech PCA-6751 <br />
|2.9.49 || Working <br />
|-<br />
! Soekris 4801-50 <br />
|2.9.48 || 3 Ethernet, 128MB, CF 512MB - Working <br />
|-<br />
!Soekris 4826-48<br />
|3.10 || 233 Mhz CPU, 128 Mbyte SDRAM, 1 Ethernet, 1 Serial, 256 Mbyte CF Flash, 2 Mini-PCI sockets, PoE. Limited power available/runs only 1 high power card (@26dB) along with another lower power card (@17dB) <br />
|-<br />
! Soekris net4801-48/50 + lan1641<br />
|3.22 || All 7 (3+4) ethernet works, USB works (tested with Huawei 3G modem), extra serial port works. And RouterOS installed on CF card.<br />
|-<br />
! ALIX 2C0 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,128Mb 433Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 2C1 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,128Mb 433Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 2C3 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,256Mb 500Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 3C1 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,128Mb 433Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 3C2 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,256Mb 500Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 2D13 <br />
| 5.2 || 3 Ethernet, 1 miniPCI ,256Mb 500Mhz Amd Geode- Working Perfect<br />
|-<br />
|}<br />
<br />
=='''3G cards'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center" data-sort-type="Model" <br />
! Model !! Tested RouterOS version !! Comments !! Format<br />
|-<br />
|AirPrime/Sierra PC 5220!<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Alcatel One Touch X020X USB<br />
(aka Longcheer WM66; Nuton NT36HD; MWalker mbd 100hu; Novacom GNS-3.5G White, SU-8200U; MTE MW610?)<br />
|v5.10 and higher<br />
| Config like [[Option_Globetrotter_HSDPA_USB_Modem]] Connected to Internet, Did not test Speed + Reliability (Alcatel OT X020X on x86) (data 0, info channel: 2)<br />
| USB<br />
|----<br />
|AnyData ADU E100A<br />
(aka "USB Wireless HSDPA/UMTS 2.1GHz GSM/GPRS/EGPRS 900/17000MHz/CDMA 1x EVDO Rev.A")<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|AnyData ADU 500A USB <br />
(aka "USB Wireless HSDPA/UMTS 2.1GHz GSM/GPRS/EGPRS 900/1800MHz/CDMA 1x EVDO Rev.A")<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Audiovox PC5220 CDMA Dual Band 1XEV-DO PC Card <br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|C-motech CNU-680 CDMA 1x EV-DO 450Mhz USB Modem (used by Triatel) [http://www.cmotech.com/eng/usbModems/product.do?act=view&product_seq=55]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Dell 5520<br />
|v3.x and higher<br />
|<br />
|MiniPCI-E<br />
|----<br />
|Ericsson_F3507g_Mobile_Broadband_Module [http://3g-modem.wetpaint.com/page/Ericsson+F3507G]<br />
|v3.x and higher<br />
|Set init string AT+CFUN=1, data channel and info channel to 3.<br />
|MiniPCI-e<br />
|----<br />
|Huawei E226 USB modem, <br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E220 USB modem, E200BIS [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
| Huawei E169 USB modem (used by Tele2) [http://3g-modem.wetpaint.com/page/Huawei+E169+%28E169G%2C+E169V%2C+K3520%29]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E180 USB modem<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E1553 USB modem<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---- <br />
| Huawei E1550 [http://3g-modem.wetpaint.com/page/Huawei+E1550]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---- <br />
| Huawei E1762 USB Modem<br />
|v5.14 and higher<br />
|<br />
|USB<br />
|---- <br />
| Huawei E372 (USB) Videotron Canada<br />
|v5.15 and higher<br />
|Data channel 0 , Info channel 0, APN ihvm.videotron, Phone = *99# , Dial = ATDT ,<br />
|USB<br />
|---- <br />
| Siemens M20<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Huawei E620; <br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Kyocera KPC650 <br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Nokia CS-17 (USB)<br />
|v5.0 and higher<br />
|Data channel=2, info channel=4<br />
|USB<br />
|---<br />
|Nokia CS-18 (USB) Rogers Canada<br />
|5.12 and higher<br />
|Data channel=1, Info channel =1, APN= internet.com, Phone = *99# , Dial = ATDT , pap , Tested on rb-751 and rb-493<br />
|USB<br />
|----<br />
|Novatel EU740 <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel EU870 [http://www.novatelwireless.com/content/pdf/EU870D_datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
||Novatel MIFI 2372 Bell Canada<br />
|v5.12 and higher<br />
|Data Channel=0 , Info Channel= 0, APN = pda2.bell.ca , Phone = *99# , Dial = ATDT , pap, Tested on Rb-750UP and RB-493<br />
|USB<br />
|----<br />
|Novatel EV620 CDMA/EV-DO <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Merlin ES620 / Merlin ES720 / Ovation U720 [http://www.novatelwireless.com/index.php?option=com_content&view=article&id=177&Itemid=58]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel Merlin ES620<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Novatel Merlin S720 (HSDPA) [http://support.sprint.com/support/device/Novatel_Wireless/Merlintrade_S720_by_Novatel_Wireless-novatel_s720]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin XU870 HSDPA/3G [http://www.novatelwireless.com/content/pdf/Merlin_XU870_DataSheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel U720 Wireless CDMA Modem<br />
|v4.5 and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel U730 (Wireless HSDPA Modem) [http://www.novatelwireless.com/content/pdf/Merlin_U730_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Wireless CDMA card <br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Option Fusion UMTS Quad-GPRS<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Option Globetrotter HSDPA USB aka Teltonika ModemUSB/H7.2 (U3G150) [http://teltonika.lt/uploads/docs/ModemUSB%20H7.2%20User%20Manual%20EN.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Probably most of the cards needing the HSO driver on Linux, tested: Option Globetrotter HSDPA USB (Globetrotter iCon 225 [http://www.option.com/en/products/products/usb-modems/icon225/]<br />
|v5.12<br />
|[[Option_Globetrotter_HSDPA_USB_Modem]] see Workaround for Globetrotter devices offering no modem interface<br />
|USB<br />
|----<br />
|Option Qualcomm 3G WCDMA Model M00201-10886 (GTM378) [http://www.wireless-market.hu/dwl/OPTION_GTM378_DS_ENG.pdf]<br />
|v3.x and higher<br />
|<br />
|miniPCI-e<br />
|----<br />
|Option Qualcomm 3G CDMA Model M00301 (GTM380) [http://www.option.com/en/products/products/modules/gtm380e/]<br />
|v3.x and higher<br />
|Set data channel and info channel to 3.<br />
|miniPCI-e<br />
|----<br />
|Option Qualcomm 3G CDMA Model M00401 (GTM382) [http://www.option.com/en/products/products/modules/gtm382e/]<br />
|v3.x and higher<br />
|<br />
|miniPCI-e<br />
|----<br />
|Ericsson 3G F3607gw miniPCI-e<br />
|v3.x and higher<br />
|Set data channel and info channel to 2, set init string AT+CFUN=1<br />
|miniPCI-e<br />
|----<br />
|Sierra Aircard 595 [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_595_by_Sierra_Wireless-sierra_ac595]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Aircard 595U USB Sprint Card [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_595U_by_Sierra_Wireless-sierra_ac595u]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Sierra Wireless USB 306<br />
|v5.9 and higher<br />
|Data & Info Channel 2. For Telecom NZ use APN internet.telecom.co.nz and Phone number *99#<br />
|<br />
|----<br />
|Sierra Wireless USB 308 or AT&T Shockwave [http://www.sierrawireless.com/productsandservices/~/media/Data%20Sheet/datasheet_aircard308-310u.ashx]<br />
|v5.0rc11 and higher<br />
|AT Commands are sent through Data Channel 2 or 3.<br />
|USB<br />
|----<br />
|Sierra Wireless AirCard 312U [https://www.sierrawireless.com/productsandservices/AirCard/USBModems/aircard_312u.aspx]<br />
|v5.2 and higher<br />
|<br />
|USB<br />
|----<br />
|Sierra Wireless AirCard 580 [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_580_by_Sierra_Wireless-sierra_ac580]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 595 [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_595_by_Sierra_Wireless-sierra_ac595]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 597E [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_597E_by_Sierra_Wireless-sierra_597e]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Sierra Wireless AirCard 875 [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_875_spec.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 880 [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880_spec.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 880 E [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880E_1.1spec.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Sierra Wireless AirCard 881 [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880_spec.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 881 E [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880E_1.1spec.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Sierra Wireless EM5625 [http://services.koretelematics.com/devices/images%5CDevices%5CSierra%20Wireless%5CEM-5625%5CEM-5625%20-%20SpecSheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5720 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC5720.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5725 [http://www.hy-line.de/fileadmin/hy-line/communication/PR/Text/Flyer_MC5725.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8705 [http://www.m2mconnectivity.com.au/sites/default/files/brochures/Sierra_Wireless_AirPrime_MC_Series_Intelligent_Embedded_Modules.pdf]<br />
|v5.1 and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8755 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC8755_65.pdf]<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Sierra Wireless MC8755 for Europe [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC8755_65.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8765 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC8755_65.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8775 [http://3g-modem.wetpaint.com/page/Sierra+Wireless+MC8775+%26+MC8775v]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8780 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/MC_8780_8781_Datasheet_hires_web.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5725 [http://www.hy-line.de/fileadmin/hy-line/communication/PR/Text/Flyer_MC5725.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5727 [http://www.rell.com/resources/RellDocuments/SYS_26/Sierra%20Wireless_MC5727.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8785<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8790 [http://www.sierrawireless.com/productsandservices/AirPrime/Wireless_Modules/High-speed/~/media/Data%20Sheet/AirPrime_datasheets/Sierra_Wireless_AirPrime_MC_Series_Intelligent_Embedded_Modules.ashx]<br />
|v3.x and higher<br />
|Few models do not send echo for input commands, modem does not work properly.<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8792 [http://www.sierrawireless.com/productsandservices/AirPrime/Wireless_Modules/High-speed/~/media/Data%20Sheet/AirPrime_datasheets/Sierra_Wireless_AirPrime_MC_Series_Intelligent_Embedded_Modules.ashx]<br />
|v5.2 and higher<br />
|Info works only in channel 3. Channels 4 and 5 has limited AT set. datachannel=4, infochannel=3 <br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8781 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/MC_8780_8781_Datasheet_hires_web.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless Sierra 598 (Sprint) USB [http://www.sierrawireless.com/product/~/media/Data%20Sheet/datasheet_aircardusb598.ashx]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Sierra Wireless MP3G - EVDO<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Sierra Wireless MP3G - UMTS/HSPA<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Sierra Wireless Compass 885 (USB) [http://www.insitefleet.com/documents/Compass_885_Datasheet_web.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Silicon Labs MobiData GPRS USB Modem<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Sprint U301/301U 4G wireless card [http://support.sprint.com/support/device/Sprint/U301USB_Device_Sprint_3G4G_Mobile_Broadband-dvc1020001prd]<br />
|v4.6 and higher<br />
|C-MOTECH Co, FW301DOWMX, QUALCOMM Patch 33504--Tested with v4.11 on RB433UAH, Data CH=1 Info CH=3 Phone #777 for Sprint in US<br />
|USB<br />
|----<br />
|Sprint U300/300U 4G wireless card [http://support.sprint.com/support/device/Sprint/3G4G_USB_Modem_U300-franklin_u300]<br />
|v4.6 and higher<br />
|C-MOTECH Co, FW301DOWMX, QUALCOMM Patch 33504 <br />
|USB<br />
|----<br />
|Franklin M600 3G/4G wireless card [http://www.franklinwireless.com/image/ebrochure/M600_datasheet_v1.pdf]<br />
|v5.x and higher<br />
|only 3G mode <br />
|MiniPCI-e<br />
|----<br />
|Verizon Express Network PC5220 (AirPrime 5220) <br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|ZTE AC8700 <br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|ZTE MF620 / MF622 [http://wwwen.zte.com.cn/endata/mobile/UK/UK_Instruction/201011/P020101118724987299606.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|ZTE MF620 / MF622 (3G) [http://wwwen.zte.com.cn/endata/mobile/UK/UK_Instruction/201011/P020101118724987299606.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|ZTE MF100 [http://www.3gmodem.com.hk/ZTE/MF100.html]<br />
|v5.11 and higher<br />
|Set info channel = 1, data channel = 2<br />
|USB<br />
|----<br />
|ZTE MF680 [http://www.3gmodem.com.hk/ZTE/MF680.html]<br />
|v5.4 and higher<br />
|Used by 3 in Sweden. Set data chanel to 1<br />
|USB<br />
|----<br />
|ZTE MF668 [http://wwwen.zte.com.cn/en/products/mobile/mobile_detail_291.jsp?mobileName=MF668]<br />
|v4.5 and higher<br />
|for Rogers Wireless (Canada) Set APN: isp.apn and Info & Data Channel to 1<br />
|USB<br />
|----<br />
|T-Mobile (Germany) Web´n´Walk Box Micro (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Vodafone (Germany) Easybox 2 (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Surfbox Mini (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|E-Plus & Base (Germany) USB Minimodem (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E600<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin V640/XV620 [http://www.novatelwireless.com/images/pdf/Merlin_XV620_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel Merlin V620/S620 [http://www.novatelwireless.com/content/pdf/Merlin_V620_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin EX720/V740/X720 [http://www.novatelwireless.com/images/pdf/Merlin_X720_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel Merlin V720/S720/PC720 [http://www.novatelwireless.com/content/pdf/Merlin_PC720_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin XU870 HSDPA/3G [http://www.novatelwireless.com/images/pdf/Merlin_XU870_DataSheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel X950D [http://www.novatelwireless.com/content/pdf/Merlin_X950D_datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel ES620/ES720/U720/USB720<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel E725/E726 [http://www.novatelwireless.com/content/pdf/Expedite_E725_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Vodafone EU740/Novatel non-Vodafone EU740<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Vodafone K3565/Huawei E160 [http://3g-modem.wetpaint.com/page/Huawei+E160+%28E160G%2C+E160E%2C+E160X%2C+K3565%29]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel EU850D/EU860D/EU870D [http://www.novatelwireless.com/content/pdf/EU850D_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel MC930D/MC950D [http://www.novatelwireless.com/content/pdf/OvationMC950D_datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel MC727/U727 [http://www.novatelwireless.com/content/pdf/Ovation_MC727_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel Expedite EV620 CDMA/EV-DO <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Expedite EU740 HSDPA/3G, Dell Wireless 5500 Mobile/Dell Wireless 5505 Mobile <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Expedite E720 CDMA/EV-DO<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Expedite ET620 CDMA/EV-DO<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Onda H600/ZTE MF330<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
| BP3-USB & BP3-EXT HSDPA<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---- <br />
| ZTE MY 39 (MSM 6500 based) [http://ebookbrowse.com/manual-zte-my39-eng-pdf-d40571716]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|---- <br />
| Cricket A600<br />
|v3.x and higher<br />
|<br />
|<br />
|---- <br />
| Globetrotter HSDPA Modem Option N.V.<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
| Sony Ericsson MD300<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
| ZTE MF 626 [http://3g-modem.wetpaint.com/page/ZTE+MF626]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
| ZTE MF 627 [http://3g-modem.wetpaint.com/page/ZTE+MF627]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---<br />
| Pantech / UTStarcom UM175<br />
|v3.x and higher<br />
| <br />
|USB<br />
|---<br />
| Novatel U760 [http://www.novatelwireless.com/index.php?option=com_content&view=article&id=166]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---<br />
| ZTE K3565-Z [http://3g-modem.wetpaint.com/page/ZTE+K3565-Z+%28Vodafone%29]<br />
|v4.4 and higher<br />
|Revision: BD_P673A2V1.0.0B09 <br />
|USB<br />
|---<br />
| Novatel Expedite EV620 <br />
|v4.5 and higher<br />
|<br />
|MiniPCI-e<br />
|---<br />
| Novatel MC760 VMU [http://www.novatelwireless.com/content/pdf/Datasheet_MC760.pdf]<br />
|v4.5 adn higher<br />
| <br />
|USB<br />
|---<br />
| Franklin Wireless FW300DOWMX<br />
|v4.5 and higher<br />
| <br />
|<br />
|---<br />
| Huawei EC1260<br />
|v4.5 and higher<br />
| <br />
|USB<br />
|---<br />
| Vodafone K3520-Z [http://www.business.vodafone.com/download/getFmlDoc.do?docId=7c3f8af5-9fcf-41c4-8847-d4059a0665f0]<br />
|v4.6 and higher<br />
| <br />
|USB<br />
|---<br />
| Vodafone K3765 [http://www.3gmodem.com.hk/Huawei/K3765.html]<br />
|v4.6 and higher<br />
| <br />
|USB<br />
|---<br />
| Telstra 3G Elite<br />
|v5.x and higher<br />
| <br />
|USB<br />
|---<br />
| Vodafone [http://www.twayf.com/huawei-k4505 Huawei K4505]<br />
|v5.x and higher<br />
| Data-channel=0 Info-channel=3<br />
| USB<br />
|---<br />
| Vertex VW 110<br />
|v5.x and higher<br />
| <br />
|<br />
|---<br />
| ZTE MF112 [http://www.3gmodem.com.hk/ZTE/MF112.html]<br />
|v5.x and higher<br />
| Power issues on mipsbe boards<br />
|USB<br />
|---<br />
| Huawei ET127<br />
|v5.x and higher<br />
| <br />
|3G<br />
|---<br />
| Huawei EC1261<br />
|v5.x and higher<br />
| <br />
|USB<br />
|---<br />
| Huawei E173 [http://3g-modem.wetpaint.com/page/Huawei+E173]<br />
|v5.x and higher<br />
| <br />
|USB<br />
|---<br />
| ZTE MF190 [http://wwwen.zte.com.cn/endata/mobile/info/201102/t20110209_219190.html]<br />
|v5.x and higher<br />
|Data channel=3 and info Channel=1<br />
|USB<br />
|---<br />
|ZTE MF102 [http://wwwen.zte.com.cn/en/products/mobile/mobile_detail_291.jsp?mobileName=ZTE%20MF102]<br />
|v5.x and higher<br />
|Works! Possible that need to change data channel=2 and info channel=2<br />
|USB<br />
|---<br />
|China TeleCom or ZTE AC682<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Option Globetrotter GT380<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Simcom 5220<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Huawei K3770<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Novatel USB551L (Verizon) [http://www.novatelwireless.com/content/pdf/MC551NVTLDatasheetRev2.pdf]<br />
|v5.9 and higher<br />
|Only 3G support (No LTE support)<br />
|UB<br />
|---<br />
|Novatel Wireless MIFI4510<br />
|<br />
|Not supported<br />
|<br />
|---<br />
|ZTE MC2718 [http://www.headele.com/Datasheet/EVDO/MC2716&MC2718%20Technical%20Specifications%20and%20Hardware%20Design.pdf]<br />
|v5.8 and higher<br />
|Possible data-channel=0 info-channel=1 GPS(NMEA)=4<br />
|MiniPCI-e<br />
|---<br />
|LG-VL600 (Verizon)<br />
|<br />
|Not supported<br />
|<br />
|---<br />
|Huawei EC156 [http://www.tataphoton.com/download/user-manuals/Huawei-EC156-User-Manual.pdf]<br />
|v5.8 and higher<br />
|<br />
|USB<br />
|---<br />
|K3806 [http://vodafone.com/content/dam/vodafone/about/what/devices/mobile_broadband/pdf/vodafonek3806specs.pdf]<br />
|v5.8 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE MF-210V [http://www.smartm2msolutions.com/Recursos/downloads/MF210.pdf]<br />
|v5.9 and higher<br />
|<br />
|MiniPCI-e<br />
|---<br />
|Huawei E398 [http://www.twayf.com/huawei-e398-lte-modem]<br />
|v5.9 and higher<br />
|<br />
|USB<br />
|---<br />
| Huawei E367<br />
|v5.11 and higher<br />
|<br />
| USB<br />
|---<br />
|Huawei EM770 [http://www.arm9.net/datasheet/EM770.pdf]<br />
|v5.11 and higher<br />
|<br />
|MiniPCI-e<br />
|---<br />
|Nokia E52 (Series 60)<br />
|v5.12 and higher<br />
|Set Usb mode to "PC Suite" in phone menu, Baud rate - 115200, Ports - 0/0, APN - internet, no modem init string, Dial number - *99#<br />
|USB<br />
|---<br />
|Nokia 6700 Classic (Series 40)<br />
|v5.12 and higher<br />
|Set Usb mode to "PC Suite" in phone menu<br />
Baud rate - 115200<br />
Ports - 0/0<br />
APN - internet<br />
Modem init string - ATZ, Dial number - *99#<br />
<br />
Phone is charged up through the USB port<br />
|USB<br />
|---<br />
|Alcatel X220S [http://www.alcatelonetouch.com/global-en/products/mobile_broadband/ot-x220.html]<br />
|v5.13 and higher<br />
|<br />
|USB<br />
|---<br />
|MO835UP <br />
|v5.14 and higher<br />
|<br />
|USB<br />
|---<br />
|Nokia Datacard CS-11 & CS-15 <br />
|v5.14 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE MF821<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Huawei K4510 [http://www.vodafone.com/content/dam/vodafone/about/what/devices/mobile_broadband/pdf/vodafonek4510k4511specs.pdf]<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Huawei E173s<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Option3G Mini-PCI model GTM661W<br />
|<br />
|Not supported<br />
|USB<br />
|---<br />
|Option 225<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE AC682<br />
|v5.15 and higher<br />
| <br />
|USB<br />
|---<br />
|ZTE AX320<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE MF 652<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Vodafone Huawei K-4605<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Huawei E353<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|CELOT CT-680<br />
|v5.16 and higher<br />
|<br />
|USB<br />
|---<br />
|}<br />
<br />
<br />
<br />
<br />
<br />
<br />
'''*''' - Currently MikroTik RouterOS works with PPP 3G modems over serial interfaces, 4G modems with IP drivers are not supported.<br />
<br />
=='''4G LTE cards'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Tested RouterOS version !! Comments !! Format<br />
|-<br />
|---<br />
|BandRich C501 [http://www.bandrich.com/Data-Card_C500.html]<br />
|v5.12<br />
|Configure under the new "/interface lte" menu<br />
|USB<br />
|}<br />
<br />
=='''Memory cards'''==<br />
<br />
NB! New flash cards need always formatting!<br />
<br />
Legend: <br />
<br />
*V - works<br />
*X - doesn't work<br />
*? - not tested<br />
*NA - not available for this RB<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Type !! RB600 !! RB1000 !! RB433AH !! RB450G !! R493G<br />
|----<br />
|PQI 4GB 120x HiSpeed || CF || '''X''' || ? || NA || ? || ?<br />
|----<br />
|2GB Transcend 133x || CF || X || ? || NA || ? || ?<br />
|----<br />
|2GB Kingston 133x (Elite Pro, code CF/2GB-S2)|| CF || V || ? || NA || ? || ?<br />
|----<br />
|4GB Kingston 133x (Elite Pro)|| CF || ? || V || NA || ? || ?<br />
|----<br />
|4GB Kingston CF/4GBIN || CF || '''X''' || ? || NA || ? || ?<br />
|----<br />
|8GB A-Data Speedy G08GNMC7B0095|| CF || V || V || NA || ? || ?<br />
|----<br />
|16GB A-Data Speedy || CF || V || V || NA || ? || ?<br />
|----<br />
|4GB Apacer Photo Steno IV 300X || CF || '''X''' || '''X''' || NA || ? || ?<br />
|----<br />
|1GB Sandisk Ultra II BB05024GA|| CF || V || V || NA || ? || ?<br />
|----<br />
|2GB Sandisk Ultra II || CF || ? || V || NA || ? || ?<br />
|----<br />
|8GB Sandisk Ultra II || CF || ? || V || NA || ? || ?<br />
|----<br />
|8GB SanDisk Extreme III (200X,30MB/s) || CF || ? || V || NA || ? || ?<br />
|----<br />
|2.5GB Seagate ST1 (ST625211CF) || CF microdrive|| V || V || NA || ? || ?<br />
|----<br />
|8GB Seagate ST1 || CF microdrive || V || V || NA || ? || ?<br />
|----<br />
|64MB Nokia || microSD || NA || NA ||? || V || ?<br />
|----<br />
|512MB Kingston || microSD || NA || NA || V || ? || ?<br />
|----<br />
|1GB Apacer || microSD || NA || NA || V || ? || ?<br />
|----<br />
|1GB Kingston (SDC/1GB) || microSD || NA || NA || ? || X|| ?<br />
|----<br />
|2GB Kingston || microSD || NA || NA || '''X'''|| [[:Image:Kingston_rubbish.jpg | '''X''']] || ?<br />
|----<br />
|2GB Traxdata || microSD || NA || NA ||? || [[:Image:Traxdata_microSD_working.jpg | '''V''']] || ?<br />
|----<br />
|4GB Apacer SDHC (class 6) || microSD|| NA || NA || V || X || ?<br />
|----<br />
|4GB Axiz || microSD|| NA || NA || V || ? || ?<br />
|----<br />
|4GB Kingston || microSD || NA || NA || V || ? || ?<br />
|----<br />
|4GB Kingston SDHC (C04G JAPAN class 4) || microSD || NA || NA || V|| ? || ?<br />
|----<br />
|4GB Maxell SDHC (class 2) P-series || microSD || NA || NA || ?|| ? || V<br />
|----<br />
|4GB Transcend SDHC || microSD || NA || NA || V|| ? || ?<br />
|----<br />
|4GB Sandisk Mobile Ultra Micro SDHC (with card reader) || microSD || NA || NA || ? || V || ?<br />
|----<br />
|8GB Sandisk SDHC (0733702482DLE) || microSD || NA || NA || V || V || ?<br />
|----<br />
|8GB Sandisk Mobile microSDHC (SDSDQ-8192-A11M) || microSD || NA || NA || ? || V|| ?<br />
|----<br />
|8GB Sandisk Mobile Ultra SDHC (Class 6) || microSD || NA || NA || ?|| V || ?<br />
|----<br />
|8GB Kingston SDHC (Class 4) || microSD || NA || NA || V|| X || ?<br />
|----<br />
|8GB ADATA micro SDHC (AUSDH8GCL6) (Class 6) || microSD || NA || NA || ? || V || ?<br />
|----<br />
|16GB Sandisk micro SDHC (SDSDQ-16384-P36M) class 2|| microSD || NA || NA || NA|| X|| ?<br />
|----<br />
|16GB Sandisk micro SDHC (0835B03279DQ) class 2|| microSD || NA || NA || V|| V|| ?<br />
|----<br />
|2GB Sandisk micro SDHC class 2|| microSD || NA || NA || NA|| X|| V<br />
|----<br />
|4GB Sandisk Mobile microSDHC (SDSDQM-004G-B35S) class 4|| microSD || NA || NA || ?|| X|| X<br />
|}<br />
<br />
Note: Pushing the "Kingston SDHC 8GB card" all the way into the socket caused the card not to work properly! It had to be pulled out ~1mm for it to work!<br />
<br />
==802.11a/b/g wireless cards==<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! Platform !!ROS!! Result<br />
|----<br />
|TechnicLan [http://www.techniclan.com/Wireless_mPCI_TMP-5414A_11abg_108Mbps_Atheros_solution,p,74.html TMP-5414A]|| miniPCI ||All RouterBOARDs||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=23 WLM54AG-20]|| miniPCI ||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=25 WLM54A-26]|| miniPCI ||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|----<br />
| SparkLAN WMIA-165G||miniPCI||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
| SparkLAN WMIA-166AG||miniPCI||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
| SparkLAN WMIA-166AGH||miniPCI||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|Alfa AWPCI 085 H||miniPCI||RB1xx/RB333/RB4xx/x86||2.9&3.x||All just perfect<br />
|----<br />
|TP-Link TL-WN550/551||PCI||x86||2.9&3.x||Perfect 19dB rated, stable at 21<br />
|----<br />
|TP-Link TL-WN650/651||PCI||x86||2.9&3.x||Perfect 19dB rated, stable at 21. Unstable with compression activated<br />
|----<br />
|D-Link AG530 a/b/g (both rev.A1 and A2)||PCI||x86||2.9&3.x||Perfect. Works perfect, in both 2.4 and 5.x GHz<br />
|----<br />
|D-Link DWL-G510||PCI||x86||only 2.9.x tested||Perfect. Tested Rev A1<br />
|----<br />
|D-Link DWL-G520||PCI||x86||2.9.x & 3.x||Works well.<br />
|----<br />
|D-Link DWL-G520+A/RaLink 2591 Chipset||PCI||x86||4.9|| NOT Work!<br />
|----<br />
|Gigabyte b/g GN-WI01GT||miniPCI-e||x86||3.x||Works also in RouterBOARDs with miniPCI-e slot<br />
|----<br />
|Senao NL-2511CD EXT2||PCMCIA||x86&rb230||only 2.9x tested||Perfect. Just about the most sensitive card i used, in the good sense. Only 11b. <br />
|----<br />
|Planet WL-8310||PCI||x86||only 2.9.x tested||Perfect. Stability.<br />
|----<br />
|Netgear WG311T 108||PCI||x86||only 2.9x tested||Perfect. stability<br />
|----<br />
|SMC SMCWPCIT-G ||PCI||x86||3.x tested||Perfect on A/B/G. <br />
|----<br />
|Wistron DCMA-81 || miniPCI ||x86,rb||2.9.xx, 3.xx||Perfect on A/B/G with or without compression.<br />
|----<br />
|Wistron DCMA-82|| miniPCI ||rb||3.xx||Works on some RB, but on 2/3 of my RB433 it causes the board to reboot when enabled. Many other people have had similar experiences. Not recommended. Maybe OK on 133<br />
|----<br />
|Senao NMP-8602|| miniPCI ||x86&rb411||2.9x,3.x tested||Perfect on a/b/g<br />
|----<br />
|Dbii [http://dbii.com/f20.html F20]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on B/G, too thick for 3 in rb433<br />
|----<br />
|Dbii [http://dbii.com/f50.html F50]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on A, too thick for 3 in rb433<br />
|----<br />
|Dbii [http://www.dbii.com/f20-PRO.html F20-PRO]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on B/G, too thick for 3 in rb433<br />
|----<br />
|Dbii [http://www.dbii.com/f50-PRO.html F50-PRO]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on A, too thick for 3 in rb433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/xr2.php XR2]|| miniPCI ||RB433||3.x||works as advertised, too thick for 3 in rb433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/xr5.php XR5]|| miniPCI ||RB433, x86||3.x||works as advertised, too thick for 3 in rb433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/sr9.php SR9]|| miniPCI ||RB433||3.x||works as advertised, thin enough to load 3 in RB433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/xr9.php XR9]|| miniPCI ||RB411 & RB433||3.x||works as advertised, thin enough to place cards above, but antenna port may contact cards below<br />
|----<br />
|Valemount [http://www.staros.com/documentation/KXS30SG%20Sell%20Sheet.pdf KXS30SG]||miniPCI||RB433||3.2 & 4.2 tested||B/G only, no A. Big heat sink means card should be installed on highest mount when other cards being used. High power consumption can cause power problems, otherwise works perfectly. <br />
|----<br />
|Zcomax [http://www.zcomax.cz/Xg650.aspx XG-650]|| miniPCI ||RB112 & RB433||4.2 & 4.6||Not working (driver doesnt work / exist). It has a TI TNETW1130GVF chipset.<br />
|----<br />
|AR5BMB5 || miniPCI ||RB411,x86||3.xx, 4.3||Not working. Atheros chipset.<br />
|}<br />
<br />
=== 802.11n wireless cards ===<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! ROS!! Result<br />
|----<br />
|[http://store.dcsindo.com/interfaces/wireless-minipci/wmia-198n.html SparkLAN WMIA-198N]|| miniPCI ||4x, 5x||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=96 WLM200N5-23]|| miniPCI ||4.0b3||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=32 WLM200NX]|| miniPCI ||4.0b3||Perfect, Stable<br />
|----<br />
|----<br />
|Dbii [http://dbii.com/f52N-PRO.html F52N-PRO]|| miniPCI ||5.1||Stable<br />
|----<br />
|----<br />
|RouterBOARD [http://www.routerboard.com/prices.html R2N]|| miniPCI ||4.0b3||works<br />
|----<br />
|RouterBOARD [http://www.routerboard.com/prices.html R52N]|| miniPCI ||4.0b3||works<br />
|----<br />
|TP-Link Wireless N (2T2R)|| miniPCI ||4.0b3||works<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/sr71a.php SR71-A]|| miniPCI ||4.0b3||works<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/sr71a.php SR71-A]|| miniPCI ||4.0b3||works<br />
|}<br />
<br />
=== USB wireless cards ===<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! ROS !! Result<br />
|----<br />
|802 b/g/n AR9271 || USB || 5.0rc4 || works<br />
|----<br />
|802 b/g/n AR9271 Ubiquiti WiFiStation || USB || 5.8 x86 || works on N but causes reboot on G<br />
|----<br />
|802 b/g/n AR9271 ALFA AWUS036NHA || USB || 5.14 x86 || works<br />
|----<br />
|802 b/g/n AR9170 NETGEAR WN111v2 || USB || 5.16 x86 || Don't recognize<br />
|}<br />
<br />
==T1/E1==<br />
<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! Platform !!ROS!! Result<br />
|----<br />
|Farsite FarSync TE1||PCI||x86||3.15||supported<br />
|----<br />
|}<br />
<br />
''Note: Since v3.15 RouterOS doesn't support any Sync/T1/E1 cards except select Farsite models''<br />
<br />
==GPS==<br />
<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Connection !! Platform !!ROS!! Result<br />
|----<br />
|EXAMPLE||USB||x86||3.30||supported<br />
|----<br />
|}<br />
<br />
==Storage controllers (SAS/SCSI) ==<br />
<br />
Post only tests since RouterOS v5beta5<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !! Motherboard !! RouterOS !! Works !! Type<br />
|----<br />
|HP||Smart Array E200i||x86||v5rc1||No || SCSI<br />
|----<br />
|3ware||3w-9xxx||x86||v5rc8||Yes || SCSI<br />
|----<br />
|Areca||arcmsr ||x86||v5rc8||Yes || SCSI<br />
|----<br />
|Megaraid||Megaraid (some Dell servers)||x86||v5rc8||Yes || SCSI<br />
|}<br />
<br />
== LCD panels==<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !! Motherboard !! RouterOS !! Works / Doesn't <br />
|----<br />
|Crystalfontz||CFA-633v1.5||x86||v5RC10||[[Crystalfontz_CFA-633|Works]]<br />
|----<br />
|Crystalfontz||CFA-633v1.3||x86||v5RC7-RC10||[[Crystalfontz_CFA-633|Didn't work]]<br />
|---<br />
|}<br />
<br />
==USB storage==<br />
<br />
{{Note | USB storage device that does not require special drivers or is compatible to work with generic USB storage drivers will work. Devices include external hard drives, USB flash drives}}<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !!Works / Doesn't <br />
|---<br />
|generic||USB flash drive||Works<br />
|---<br />
|Kingston||DataTraveler 2GB||Works<br />
|}<br />
<br />
==SFP modules==<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !! Rate !! Connector/Cable type !! Wavelength !! Tested with !! Works / Doesn't <br />
|---<br />
|Finisair || FCLF-8521-3 || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Finisair || FCLF-8521-3-MD || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Unica || SFP-1.25G-T || 1000M || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Dell || FTLX8571D3BCL || 1,25G || LC, MM || 850 || RB2011LS-IN || Works!<br />
|---<br />
|Unica || GP-3124-L2CD-C || 1,25G || LC, MM || 1310 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-SFP-T || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-WDM-0210BSD || 1,25G ||Bi-Di SC, SM || 1550/1310 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-WDM-0210ASD || 1,25G || Bi-Di SC, SM || 1310/1550 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-SFP-0310D || 1,25G || LC, MM || 1310 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-SFP-0301D || 1,25G || LC, MM || 850 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSP-T(10/100/1000) || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSPL-53-BX || 1,25G || Bi-Di LC, MM|| 1550/1310 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSPL-35-BX || 1,25G || Bi-Di LC, MM|| 1310/1550 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSP -LX-SM || 1,25G || LC, MM/SM|| 1310 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSP-SX-MM || 1,25G || LC, MM || 850 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGT-R1T4-05I1 || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-37А4-0531 || 1,25G || Bi-Di LC, MM|| 1550/1310 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-16А4-0531 || 1,25G || Bi-Di LC, MM|| 1310/1550 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-1354-0531 || 1,25G || LC, MM|| 1310 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-5854-0511 || 1,25G || LC, MM|| 850 || RB2011LS-IN || Works!<br />
|---<br />
|MikroTik || RB SFP3401 || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP5602D-53 || 155M~2.63G || Bi-Di LC, MM|| 1550/1310 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP5602D-35 || 155M~2.63G || Bi-Di LC, MM|| 1310/1550 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP3420D || 1,25G || LC, MM|| 1310 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP3903D || 10G || LC, MM|| 850 || RB2011LS-IN and TBA || Works. Available in Q3!<br />
|---<br />
<br />
|}<br />
<br />
==USB serial adapters==<br />
<br />
{{Note| when USB serial port is connected RouterOS might attach serial console on the port. Before using it for something else, disable the console on the interface}}<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !!Works / Doesn't <br />
|---<br />
| ||USB U209-000-R Serial-Port||Works<br />
|}<br />
<br />
==USB Ethernet==<br />
<br />
{{Note | see if device works with one of these linux kernel modules. If yes, it will be possible to use it on RouterOS}}<br />
<br />
RouterOS on x86 have these modules enabled<br />
*USB_PEGASUS<br />
*USB_RTL8150<br />
*USB_USBNET<br />
*USB_NET_AX8817X<br />
*USB_NET_CDCETHER<br />
*USB_HSO<br />
<br />
RouterOS on mips have these modules enabled:<br />
*USB_NET_MCS7830<br />
*USB_NET_AX8817X<br />
*USB_NET_CDCETHER<br />
*USB_HSO<br />
*USB_USBNET<br />
<br />
AX88178 (USB2.0 Gigabit Ethernet) recognized but not working.<br />
<br />
[[Category:Hardware]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Supported_Hardware&diff=23645Supported Hardware2012-05-17T12:07:04Z<p>Megis: /* SFP modules */</p>
<hr />
<div>''This page should be edited by the user community to reflect their tested hardware and version used.''<br />
<br />
See also: [http://wiki.mikrotik.com/wiki/Manual:Driver_list Device driver list] in manual <br />
<br />
=='''Motherboards'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Vendor !! Model !! ROS version !! Result<br />
|-<br />
|-<br />
! Asrock || Intel 82801G chipset <br />
| 3.0-3.14 || Bad performance, locks up under heavy load, supports multi cpu, PATA not supported, integrated ethernet not recognized. Maybe it's just Asrock bad motherboard don't know if the problem is in intel 82801G chipset tested on 2 motherboards, never tested on 2.9.x <br />
|-<br />
! ASUS ||P8H67-V (Intel® H67(B3), 3xPCI, 4xPCI-E)<br />
| 5.XX || Don't work. "Kernel Panic". Mikrotik has not driver compatibility with this motherboard. <br />
|-<br />
! ASUS || P5B-Deluxe (Intel P965, 3xPCI, 3xPCI-E)<br />
| 3.13 || Works fine on Intel Core 2 Duo E6400. Not supported PATA controller. Both integrated Gigabit NIC (Marvell Yukon 88E8056 & 88E8001) works fine but only at 100Mbps.<br />
|-<br />
! ASUS || P5B-V (Intel P965, 3xPCI, 4xPCI-E)<br />
| 3.13 || Works fine on Intel Dual Core E2180. Not supported PATA controller. Integrated Gigabit NIC Marvell Yukon 88E8001 works fine but only at 100Mbps. Winbox via MAC = problem, disconnects after 3 seconds. Winbox via IP no problem. <br />
|-<br />
! ASUS || P5KC (Intel P35, 3x PCI, 3xPCI-E)<br />
| 3.10 || Not supported PATA controller (JMicron JMB363), ROS can boot from USB flash drive; internal ethernet not recognized.<br />
|-<br />
! ASUS || P5GC-MX/1333 (2x PCI)<br />
| 3.7 || Works great for pentium dual-core e2160, hdd pata and sata, 1,5gb ram dual channel mode, except the attansic l2 ethernet onboard card is not recognized.<br />
|-<br />
! ASUS || P5GC (6xPCI)<br />
| 2.9.39 || Ethernet recognized but not working<br />
|-<br />
! ASUS || P7P55D PRO<br />
| 4.5 || Works ok, PATA controller (JMicron JM363) and internal Ethernet successfully recognized.<br />
|-<br />
! ASUS || P6T SE<br />
| 4.0 || RouterOS boots and works with SATA disk set to 'IDE compatibility mode'.<br />
|-<br />
! ASUS || A7V133-C<br />
|3.0 beta 7 || Works fine<br />
|-<br />
! ASUS || A7V600-X<br />
|3.25 || Works fine<br />
|-<br />
! EPoX || EP-4VKMI<br />
| 3.16 - 3.24 || Works fine.<br />
|-<br />
! EPoX || 8RDA+ <br />
| 3.6 || Work fine including integrated ethernet<br />
|-<br />
! Intel || D815EGEW<br />
| 2.9.x || Excellent performance under 2.9. Not tested under v3. Onboard Ethernet Works perfectly.<br />
|-<br />
! Intel || D845GVSRL<br />
| 3.7, 3.1, 2.9<br />
|Very Stable, used for 4 years<br />
|-<br />
! Intel || D945GCCRL<br />
| 2.9.43 & 3.0 beta 5 || Ethernet & DoM not recognized<br />
|-<br />
! Intel || D945GCLF2<br />
| 3.23 || 4 core's, 2gb ram, 32gb ssd, no problems.<br />
|-<br />
! Intel || D945GCPE<br />
| 3.0 beta 9 || Work fine including integrated ethernet<br />
|-<br />
! Intel || D945GCNL<br />
| 3.11 || Works fine but integrated ethernet (just disable) goes up and down on reboots multi-cpu= yes. shared IRQ for PCI devices, decrease nic performace.<br />
|-<br />
! Intel || D945GNT<br />
| 2.9.45 <br />
|Works fine<br />
|-<br />
! Intel || DG33FB<br />
| 3.7 || Works fine, Ethernet but not working (IRQ 9), set in BIOS Security/XD Tegnology to disable<br />
|-<br />
! Intel || DG950<br />
| 2.9.42 || Ethernet not recognized<br />
|-<br />
! Intel || DG965SWH<br />
| 3.0 beta 9 || Works fine, but only with SATA not IDE<br />
|-<br />
! Intel || DH67BLB3<br />
| 5.14 || Works Great with i7-2600k processor<br />
|-<br />
! Intel || DP55WG<br />
| 4.6<br />
|multi-cpu smp works great, onboard NIC not supported by RouterOS 4.6 yet though, must use pci/pci express nics<br />
|-<br />
! Intel || DQ965GFEKR (D41676)<br />
| 3.7, 3.4 <br />
|Works fine on 3.7/3.4 if multi-cpu=no, BUT 3.5-3.7 fail to boot with E4600 processor and multi-cpu=yes<br />
|-<br />
! Intel || S3210SHLC<br />
| 4.2 || Boot from USB stick. Work fine for my PPPoE server. Up to 1300 users with summary 200Mbit traffic.<br />
|-<br />
! Intel || D945GZT-M<br />
| 3.0rc4 <br />
|Works fine<br />
|-<br />
! Chaintech || AADF950<br />
|3.0 beta 5<br />
|Works fine<br />
|-<br />
! Abit || KT7E<br />
|3.0 beta 7<br />
|Works fine<br />
|-<br />
! ECS || nForce3-A<br />
|3.6<br />
|Work fine including integrated ethernet<br />
|-<br />
! ECS || P4M800PRO-M478<br />
|2.9.43<br />
|No Apparent Problems, Disabled any unneeded devices in the BIOS<br />
|-<br />
! Abit || BE6<br />
| 2.9.43 || Works<br />
|-<br />
! VIA || EPIA-MII12000<br />
| 2.9.42 || Locks up under heavy load across wireless<br />
|-<br />
! Supermicro || 5015M-MR<br />
| 2.9.28 || Motherboard is PDSMi w dual core<br />
|-<br />
! Supermicro || PDSBM-LN2+<br />
| 2.9.51 & 3.16 || http://forum.mikrotik.com/viewtopic.php?f=1&t=28184<br />
|-<br />
! Supermicro || PDSMi-LN4+<br />
| 2.9.51, 3.13, 3.20 || Very stable even with dual-cores enabled. <br />
|-<br />
! Gigabyte || GA-41M-ES2L<br />
| 3.28 || Works fine; CPU Intel Core2 Dual 2.7GHz; 2XRB44GV <br />
|-<br />
! Gigabyte || GA-6BXS<br />
| 2.9.43 || Works fine<br />
|-<br />
! Gigabyte || GA-8I848P-G<br />
| 3.6 || Work fine including integrated ethernet<br />
|-<br />
! Gigabyte || GA-8ST667 rev. 3.0<br />
| 3.13 || Works fine; CPU Intel Celeron 2,4GHz; Chipset SiS 645DX; 5xPCI; <br />
|-<br />
! Gigabyte || GA-M720-US3 rev 1.0<br />
| 4.6 || Works fine (downvolted to 1.1V)<br />
|-<br />
! Gigabyte || GA-MA790GP-UD4H<br />
| 3.30 || Works fine<br />
|-<br />
! Gigabyte || K8-NS-ULTRA<br />
| 2.9.x-3.7 || Excelent work, including both onboard ethernet (100 and 1000 lan)<br />
|-<br />
! Gigabyte || GA-MA770-DS3 (rev. 2.0)<br />
| 3.10 || Works fine and extreme stable include onboard LAN, IDE DOM can load normally <br />
|-<br />
! || Chipset P35 (Tested Using Gigabyte GA-P35-DS3L & Abit IP35)<br />
| 3.7 || Work fine but only with SATA, not IDE (Include DOM), bellow v3.7 problem with SATA too<br />
|-<br />
! Microsoft || Virtual PC 2007<br />
| 3.7 || Installs and and tries to boot.<br />
|-<br />
! VMware || Workstation v6.0.3<br />
| 3.7 || Runs Wicked Fast! I have had up to 8 Ethernet interfaces running simultaneously.<br />
|-<br />
! VMware || ESXi v4<br />
| 3.30 || Select IDE type for virtual disk - works perfectly!<br />
|-<br />
! || Xen 3.2.1 on Intel C2Q<br />
| 4.x || Installs and runs fine on HVM bootloader using Intel VT technology. Even switches to RouterOS console from Dom0 shell. Ethernet interfaces work perfectly. '''Do not install xen/kvm RouterOS packages!'''<br />
|-<br />
! DFI || AD73 Pro (Chipset VIA KT266A/VT8233ACD)<br />
| 2.9.x-3.30 || Works fine. All 5 PCI's ocupied with 1 x LAN and 6 x R52H's (3 in RouterBoard11 and 3 in RouterBoard14!)<br />
|-<br />
! DFI || AK75-EC (Chipset VIA KT133A/686B)<br />
| 3.14-3.30 || Stable. All PCI's ocupied with LAN, miniPCI-PCI adapters fitted with R5H/R52H's and XR5's<br />
|-<br />
! Fujitsu Siemens || Primergy RX100S5<br />
| 3.1, 3.7, 3.22 || Can Install from Netinstall with RAID (LSI) Controller enable. Can't install from CD and Netinstall with only SATA or PATA mode. <font color=red><b>But NOT RUN</b></font><br />
|-<br />
! MSI || 785GM-E51<br />
| 4.11 || Works fine, booted from USB stick, integrated LAN working<br />
|-<br />
|}<br />
<br />
=='''Ethernet chipsets'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Vendor !! Model !! ROS version !! Result<br />
|-<br />
! 3Com || 3c905B Cyclone 100BaseTX<br />
| 2.9.51 || Works! Extremely reliable, doesn't fully support tagged vlans<br />
|-<br />
! 3Com || 3cSOHO100-TX [Hurricane] (rev: 48)<br />
| 3.14rc1 || Works<br />
|-<br />
! 3Com || 3c905C-TX/TX-M [Tornado] (rev: 120) <br />
| 2.9.51 || Works! Extremely reliable, doesn't fully support tagged vlans<br />
|-<br />
! 3Com || 3c905C-TX/TX-M [Tornado] (rev: 116) <br />
| 2.9.51 || Works! Extremely reliable, doesn't fully support tagged vlans<br />
|-<br />
! 3Com || 3c905B-FX Fast Etherlink XL FX 100baseFx [Cyclone] (rev: 0)<br />
|2.9.43 || Works but no link in Winbox and no Graph in Dude !!!! <br />
|-<br />
! Adaptec || ANA-6944A/TX Quad 10/100MBit <br />
|>=3.20<br />
|Works<br />
|-<br />
! Compaq || NC3122 Fast Ethernet Server Adapter <br />
|3.30<br />
|recognized but not working<br />
|-<br />
! Intel || S82557 10/100MBit <br />
|2.9.43<br />
|works<br />
|-<br />
! Intel || PWLA8391GT PRO1000/GT<br />
|3.7, 3.1, 2.9<br />
|Extremely Stable, used for years<br />
|-<br />
! Intel || PWLA8391GTL PRO1000/GT<br />
|3.4<br />
|Extremely Stable, used for years<br />
|-<br />
!Intel ||82575EB & 8257GB<br />
|3.15<br />
|Added support<br />
|-<br />
!Intel || 82576 Gigabit ET Quad port<br />
|4.5<br />
|Not recognized<br />
|-<br />
!Intel || 82576 Gigabit Dual Port (e1g42et)<br />
|5.8<br />
|Works<br />
|-<br />
!Intel || 82572EI (EXPI9300PTBLK)<br />
|4.5, 4.6<br />
|Works<br />
|-<br />
!Intel || 82572GI (EXPI9400PTBLK)<br />
|4.5, 5.14<br />
|Works<br />
|-<br />
! Intel || 82574L (EXPI9301CT)<br />
|5.14<br />
|Supported in ROS 5 / Works<br />
|-<br />
! Intel || 82571EB (EXPI9404PT) QUAD COPPER<br />
|4.6, 5.14<br />
|Works<br />
|-<br />
! Intel || S82557/S82555 10/100 Mbit TX<br />
| 2.9.50 / 3.16|| Works Stable! FCC ID:EJMNPDSPD035<br />
|-<br />
! Intel || PRO 1000 MT <br />
|2.9.51<br />
|Works<br />
|-<br />
! Intel || 82541GI/PI Gigabit Ethernet Controller (rev: 5)<br />
|2.9.49<br />
|Working but with high traffic (>100M) and many packets makes drops<br />
|-<br />
|-<br />
! Intel || 10Gbit Ethernet PCI Express <br />
| 3.17 || Works<br />
|-<br />
! Intel || 82557/8/9 Ethernet Pro 100 (rev: 5)/Dual ports(Two ports/2-port)/RJ-45"<br />
| 4.10 || Works, fine! <br />
|-<br />
! D-Link || DFE-528TX rev. E1<br />
|3.13<br />
| Works<br />
|-<br />
! D-Link || DFE-580TX 4-port <br />
|3.0 beta 5<br />
|Bad card, not recommended. Hangs router<br />
|-<br />
! D-Link || DFE-530/538TX <br />
|2.9.43 - 3.x<br />
|Works well, no apparent problems.<br />
|-<br />
!D-Link || DUB-E100 USB<br />
|3.18<br />
|added support, reported to be working<br />
|-<br />
!Marvell || 88E8001 Gigabit Ethernet Controller (rev: 20)<br />
|3.13<br />
|Works<br />
|-<br />
!Marvell || 88E8056<br />
|3.6<br />
|reported to be working with some BIOS setting enabled<br />
|-<br />
! DECchip || 21143 (ZYNX ZX410 4-port cPCI)<br />
|2.9.51<br />
|Working<br />
|-<br />
! Realtek || RTL-8169 Gigabit Ethernet x4 (rev: 16)<br />
|3.0-3.11<br />
|Working Extremely reliable, used 4 mounts<br />
|-<br />
! Realtek || RTL8111 (10/100/1000Mbit)<br />
|3.10<br />
|Seems to be working only in older RouterOS v3 releases, v3.10 and before. <br />
|-<br />
! Realtek || RTL8111C, RTL8111DL (10/100/1000Mbit)<br />
|4.6 - 4.11<br />
|Working<br />
|-<br />
! Realtek || RTL8139C+<br />
|3.14<br />
|Works<br />
|-<br />
! Realtek || RTL8139D<br />
|3.x<br />
|Some work, others don't. Check for yourself.<br />
|-<br />
! Realtek || RTL-8139/8139C/8139C+ (rev: 16)<br />
| 4.9 & 4.10 || Works, fine! <br />
|-<br />
! Realtek || RTL-8029(AS) (rev: 0)"<br />
| 4.9 & 4.10 || Works, fine! <br />
|-<br />
! ZNYX || ZX346Q<br />
|3.27<br />
|Works<br />
|-<br />
! VIA || VT6102 [Rhine-II] (rev: 67)"<br />
| 4.9 & 4.10 || Works, fine! <br />
|-<br />
<br />
|}<br />
<br />
=='''x86 Systems'''==<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! ROS version !! Result<br />
|-<br />
! Dell Optiplex GX1<br />
|2.9.x-3.0<br />
|Intel onboard/cpu 450-600Mhz, eth:3com, best for wirless stations; uptime over 200d, no problems at all.<br />
|-<br />
! Compaq Presario 2282<br />
|2.9.43<br />
|With 3c905 [Boomerang], no apparent problems<br />
|-<br />
! Dell GX100<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu<br />
|-<br />
! Dell GX240<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu, IDE HDD.<br />
|-<br />
! Dell GX260<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu, IDE HDD.<br />
|-<br />
! Dell GX270<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu. IDE HDD.<br />
|-<br />
! Dell GX280<br />
|2.9.x - 3.7<br />
|Intel onboard, 2 free pci, Intel cpu, SATA HDD.<br />
|-<br />
! Dell Dimension XPS GEN 3<br />
| 2.9.x<br />
| Lan Onboard, 4 free pci, Intel cpu , SATA HDD ( Excellent Stability )<br />
|-<br />
! Dell Inspiron Desktop 518<br />
|2.9.x - 3.7<br />
|After netinsall stuck on "loading system"<br />
|-<br />
! Dell PowerEdge 860<br />
|3.x<br />
|1U Rackmount, 2x Broadcom Gigabit onboard, 1x Intel CPU (many options), 1 PCI/1 PCIe or 2 PCIe riser options, SATA HDD ONLY. (some issues with floppy netinstall)<br />
|-<br />
! Dell PowerEdge R200<br />
|>= 3.19 recommended<br />
|Severe stability and clock issues with non-current ROS. Works like a top on 3.19 though. Also, if using an SATA-to-CF converter, the license key for the CF card in an R200 will only transfer to other R200's without Mikrotik reissuing it. <br />
|-<br />
! Dell PowerEdge R210<br />
| 5.1 - 5.6<br />
|1U Rackmount. Half-depth (39cm) chassis. Dual port on-board Broadcom 5716 Gigabit Ethernet controllers. Single CPU on Intel 3420 Motherboard Chipset. Works OK and stable, once installed. Some issues with NetInstall - PXE boot works OK but install can't continue (says waiting for drivers...). Tested with Intel Gigabit ET Quad Port Server Adapter - works perfectly.<br />
|-<br />
! Dell PowerEdge R310<br />
| 5.0rc7<br />
|1U Rackmount. 2 x on-board Broadcom 5716 Gigabit Ethernet controllers. Single CPU on Intel 3420 Motherboard Chipset. Works OK and stable, once installed. Some issues with NetInstall - PXE boot works OK but install can't continue (says waiting for drivers...). Tested with Intel Gigabit ET Quad Port Server Adapter - works perfectly.<br />
|-<br />
! Dell PowerEdge 2950<br />
|3.x<br />
|2U Rackmount, Optional Redundant Power Supplies, 2x Broadcom Gigabit onboard, 2x Intel CPU (many options), 2- 8xPCIe & 1- 4xPCIe Standard (other risers available), SATA HDD ONLY, 2x internal USB - MUST SPECIAL ORDER WITHOUT RAID CONTROLLER. (some issues with floppy netinstall)}<br />
|-<br />
! HP Proliant DL380 G5<br />
|3.17<br />
|Works, but only if installed from CDROM (Netinstall to Windows mounted HDD causes issues)<br />
|-<br />
! Asus EEE PC 701<br />
|3.x<br />
|SFF Laptop, 1x10/100 ethernet (Not detected), Stock Wireless unsupported (AR5007E In Mini-PCIX slot), 630/900Mhz processor, 512MB RAM, 4GB SSD (Not detected), USB2.0 Bootable, SDHC Reader functions as a USB Stick<br />
|-<br />
! Dell PowerEdge SC1425<br />
|3.x<br />
|Rackmount, Intel Xeon 2.8 1MB 800FSB, 1024MB DDR2 PC3200 ECC, 2x Intel 82541GI Gigabit Ethernet, HD150gb SATA, USB works, very stable <br />
|-<br />
! Fujitsu Siemens Primergy RX100S5<br />
| 3.7, 3.22 || Can Install from Netinstall with RAID (LSI) Controller enable. Can't install from CD and Netinstall with only SATA or PATA mode. <font color=red><b>But NOT RUN</b></font><br />
|-<br />
! Toshiba Magnia SG20<br />
| 2.9.44 || CPU Celeron, VIA chipsets, onboard LAN Realtek and Intel, IDE HDD, PCMCIA tested with Orinoco Silver, miniPCI LT WinModem <b>not work</b><br />
|-<br />
! Advantech FWA-3800<br />
| 4.11, 4.17, 5.14 || CPU Intel Core2 Duo 2,93GHz, 2GB RAM DDR2, 6 x Intel 1Gbps PCIe NIC, 1U size, works good as a BGP router. If you have troubles with MT 5.x on it, try to reset BIOS (by battery remove).<br />
|-<br />
|}<br />
<br />
=='''Embedded Controllers'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! ROS version !! Result<br />
|-<br />
! WRAP.1E-2<br />
| 2.9.51, 3.7 || 3 Ethernet, 1 miniPCI, 128 MB - Working<br />
|-<br />
! WRAP.2E <br />
| 2.9.51, 3.7, 3.9, 3.10 || 1 Ethernet, 2 MiniPCI, 128 MB - Work fine<br />
|-<br />
! ALIX 2-2 <br />
| 2.9.48 || 2 Ethernet, 2 miniPCI - Working<br />
|-<br />
! Adlink cPCI-6770 Low Power Pentium III <br />
|2.9 and 3.0 || CompactPCI CPU Module - Working, excellent performance!<br />
|-<br />
! Advantech PCA-6751 <br />
|2.9.49 || Working <br />
|-<br />
! Soekris 4801-50 <br />
|2.9.48 || 3 Ethernet, 128MB, CF 512MB - Working <br />
|-<br />
!Soekris 4826-48<br />
|3.10 || 233 Mhz CPU, 128 Mbyte SDRAM, 1 Ethernet, 1 Serial, 256 Mbyte CF Flash, 2 Mini-PCI sockets, PoE. Limited power available/runs only 1 high power card (@26dB) along with another lower power card (@17dB) <br />
|-<br />
! Soekris net4801-48/50 + lan1641<br />
|3.22 || All 7 (3+4) ethernet works, USB works (tested with Huawei 3G modem), extra serial port works. And RouterOS installed on CF card.<br />
|-<br />
! ALIX 2C0 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,128Mb 433Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 2C1 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,128Mb 433Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 2C3 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,256Mb 500Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 3C1 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,128Mb 433Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 3C2 <br />
| 2.9,3.0 || 2 Ethernet, 2 miniPCI ,256Mb 500Mhz Amd Geode- Working Perfect<br />
|-<br />
! ALIX 2D13 <br />
| 5.2 || 3 Ethernet, 1 miniPCI ,256Mb 500Mhz Amd Geode- Working Perfect<br />
|-<br />
|}<br />
<br />
=='''3G cards'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center" data-sort-type="Model" <br />
! Model !! Tested RouterOS version !! Comments !! Format<br />
|-<br />
|AirPrime/Sierra PC 5220!<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Alcatel One Touch X020X USB<br />
(aka Longcheer WM66; Nuton NT36HD; MWalker mbd 100hu; Novacom GNS-3.5G White, SU-8200U; MTE MW610?)<br />
|v5.10 and higher<br />
| Config like [[Option_Globetrotter_HSDPA_USB_Modem]] Connected to Internet, Did not test Speed + Reliability (Alcatel OT X020X on x86) (data 0, info channel: 2)<br />
| USB<br />
|----<br />
|AnyData ADU E100A<br />
(aka "USB Wireless HSDPA/UMTS 2.1GHz GSM/GPRS/EGPRS 900/17000MHz/CDMA 1x EVDO Rev.A")<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|AnyData ADU 500A USB <br />
(aka "USB Wireless HSDPA/UMTS 2.1GHz GSM/GPRS/EGPRS 900/1800MHz/CDMA 1x EVDO Rev.A")<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Audiovox PC5220 CDMA Dual Band 1XEV-DO PC Card <br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|C-motech CNU-680 CDMA 1x EV-DO 450Mhz USB Modem (used by Triatel) [http://www.cmotech.com/eng/usbModems/product.do?act=view&product_seq=55]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Dell 5520<br />
|v3.x and higher<br />
|<br />
|MiniPCI-E<br />
|----<br />
|Ericsson_F3507g_Mobile_Broadband_Module [http://3g-modem.wetpaint.com/page/Ericsson+F3507G]<br />
|v3.x and higher<br />
|Set init string AT+CFUN=1, data channel and info channel to 3.<br />
|MiniPCI-e<br />
|----<br />
|Huawei E226 USB modem, <br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E220 USB modem, E200BIS [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
| Huawei E169 USB modem (used by Tele2) [http://3g-modem.wetpaint.com/page/Huawei+E169+%28E169G%2C+E169V%2C+K3520%29]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E180 USB modem<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E1553 USB modem<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---- <br />
| Huawei E1550 [http://3g-modem.wetpaint.com/page/Huawei+E1550]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---- <br />
| Huawei E1762 USB Modem<br />
|v5.14 and higher<br />
|<br />
|USB<br />
|---- <br />
| Huawei E372 (USB) Videotron Canada<br />
|v5.15 and higher<br />
|Data channel 0 , Info channel 0, APN ihvm.videotron, Phone = *99# , Dial = ATDT ,<br />
|USB<br />
|---- <br />
| Siemens M20<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Huawei E620; <br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Kyocera KPC650 <br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Nokia CS-17 (USB)<br />
|v5.0 and higher<br />
|Data channel=2, info channel=4<br />
|USB<br />
|---<br />
|Nokia CS-18 (USB) Rogers Canada<br />
|5.12 and higher<br />
|Data channel=1, Info channel =1, APN= internet.com, Phone = *99# , Dial = ATDT , pap , Tested on rb-751 and rb-493<br />
|USB<br />
|----<br />
|Novatel EU740 <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel EU870 [http://www.novatelwireless.com/content/pdf/EU870D_datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
||Novatel MIFI 2372 Bell Canada<br />
|v5.12 and higher<br />
|Data Channel=0 , Info Channel= 0, APN = pda2.bell.ca , Phone = *99# , Dial = ATDT , pap, Tested on Rb-750UP and RB-493<br />
|USB<br />
|----<br />
|Novatel EV620 CDMA/EV-DO <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Merlin ES620 / Merlin ES720 / Ovation U720 [http://www.novatelwireless.com/index.php?option=com_content&view=article&id=177&Itemid=58]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel Merlin ES620<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Novatel Merlin S720 (HSDPA) [http://support.sprint.com/support/device/Novatel_Wireless/Merlintrade_S720_by_Novatel_Wireless-novatel_s720]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin XU870 HSDPA/3G [http://www.novatelwireless.com/content/pdf/Merlin_XU870_DataSheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel U720 Wireless CDMA Modem<br />
|v4.5 and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel U730 (Wireless HSDPA Modem) [http://www.novatelwireless.com/content/pdf/Merlin_U730_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Wireless CDMA card <br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Option Fusion UMTS Quad-GPRS<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Option Globetrotter HSDPA USB aka Teltonika ModemUSB/H7.2 (U3G150) [http://teltonika.lt/uploads/docs/ModemUSB%20H7.2%20User%20Manual%20EN.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Probably most of the cards needing the HSO driver on Linux, tested: Option Globetrotter HSDPA USB (Globetrotter iCon 225 [http://www.option.com/en/products/products/usb-modems/icon225/]<br />
|v5.12<br />
|[[Option_Globetrotter_HSDPA_USB_Modem]] see Workaround for Globetrotter devices offering no modem interface<br />
|USB<br />
|----<br />
|Option Qualcomm 3G WCDMA Model M00201-10886 (GTM378) [http://www.wireless-market.hu/dwl/OPTION_GTM378_DS_ENG.pdf]<br />
|v3.x and higher<br />
|<br />
|miniPCI-e<br />
|----<br />
|Option Qualcomm 3G CDMA Model M00301 (GTM380) [http://www.option.com/en/products/products/modules/gtm380e/]<br />
|v3.x and higher<br />
|Set data channel and info channel to 3.<br />
|miniPCI-e<br />
|----<br />
|Option Qualcomm 3G CDMA Model M00401 (GTM382) [http://www.option.com/en/products/products/modules/gtm382e/]<br />
|v3.x and higher<br />
|<br />
|miniPCI-e<br />
|----<br />
|Ericsson 3G F3607gw miniPCI-e<br />
|v3.x and higher<br />
|Set data channel and info channel to 2, set init string AT+CFUN=1<br />
|miniPCI-e<br />
|----<br />
|Sierra Aircard 595 [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_595_by_Sierra_Wireless-sierra_ac595]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Aircard 595U USB Sprint Card [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_595U_by_Sierra_Wireless-sierra_ac595u]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Sierra Wireless USB 306<br />
|v5.9 and higher<br />
|Data & Info Channel 2. For Telecom NZ use APN internet.telecom.co.nz and Phone number *99#<br />
|<br />
|----<br />
|Sierra Wireless USB 308 or AT&T Shockwave [http://www.sierrawireless.com/productsandservices/~/media/Data%20Sheet/datasheet_aircard308-310u.ashx]<br />
|v5.0rc11 and higher<br />
|AT Commands are sent through Data Channel 2 or 3.<br />
|USB<br />
|----<br />
|Sierra Wireless AirCard 312U [https://www.sierrawireless.com/productsandservices/AirCard/USBModems/aircard_312u.aspx]<br />
|v5.2 and higher<br />
|<br />
|USB<br />
|----<br />
|Sierra Wireless AirCard 580 [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_580_by_Sierra_Wireless-sierra_ac580]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 595 [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_595_by_Sierra_Wireless-sierra_ac595]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 597E [http://support.sprint.com/support/device/Sierra_Wireless/AirCard_597E_by_Sierra_Wireless-sierra_597e]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Sierra Wireless AirCard 875 [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_875_spec.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 880 [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880_spec.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 880 E [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880E_1.1spec.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Sierra Wireless AirCard 881 [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880_spec.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Sierra Wireless AirCard 881 E [http://www.nucleusnetworks.co.uk/3g-data-card/docs/sierra_aircard_880E_1.1spec.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Sierra Wireless EM5625 [http://services.koretelematics.com/devices/images%5CDevices%5CSierra%20Wireless%5CEM-5625%5CEM-5625%20-%20SpecSheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5720 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC5720.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5725 [http://www.hy-line.de/fileadmin/hy-line/communication/PR/Text/Flyer_MC5725.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8705 [http://www.m2mconnectivity.com.au/sites/default/files/brochures/Sierra_Wireless_AirPrime_MC_Series_Intelligent_Embedded_Modules.pdf]<br />
|v5.1 and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8755 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC8755_65.pdf]<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Sierra Wireless MC8755 for Europe [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC8755_65.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8765 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/Flyer_MC8755_65.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8775 [http://3g-modem.wetpaint.com/page/Sierra+Wireless+MC8775+%26+MC8775v]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8780 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/MC_8780_8781_Datasheet_hires_web.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5725 [http://www.hy-line.de/fileadmin/hy-line/communication/PR/Text/Flyer_MC5725.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC5727 [http://www.rell.com/resources/RellDocuments/SYS_26/Sierra%20Wireless_MC5727.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8785<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8790 [http://www.sierrawireless.com/productsandservices/AirPrime/Wireless_Modules/High-speed/~/media/Data%20Sheet/AirPrime_datasheets/Sierra_Wireless_AirPrime_MC_Series_Intelligent_Embedded_Modules.ashx]<br />
|v3.x and higher<br />
|Few models do not send echo for input commands, modem does not work properly.<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8792 [http://www.sierrawireless.com/productsandservices/AirPrime/Wireless_Modules/High-speed/~/media/Data%20Sheet/AirPrime_datasheets/Sierra_Wireless_AirPrime_MC_Series_Intelligent_Embedded_Modules.ashx]<br />
|v5.2 and higher<br />
|Info works only in channel 3. Channels 4 and 5 has limited AT set. datachannel=4, infochannel=3 <br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless MC8781 [http://www.hy-line.de/fileadmin/hy-line/communication/hersteller/Sierra_Wireless/Dokumente/MC_8780_8781_Datasheet_hires_web.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Sierra Wireless Sierra 598 (Sprint) USB [http://www.sierrawireless.com/product/~/media/Data%20Sheet/datasheet_aircardusb598.ashx]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Sierra Wireless MP3G - EVDO<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Sierra Wireless MP3G - UMTS/HSPA<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|Sierra Wireless Compass 885 (USB) [http://www.insitefleet.com/documents/Compass_885_Datasheet_web.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Silicon Labs MobiData GPRS USB Modem<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Sprint U301/301U 4G wireless card [http://support.sprint.com/support/device/Sprint/U301USB_Device_Sprint_3G4G_Mobile_Broadband-dvc1020001prd]<br />
|v4.6 and higher<br />
|C-MOTECH Co, FW301DOWMX, QUALCOMM Patch 33504--Tested with v4.11 on RB433UAH, Data CH=1 Info CH=3 Phone #777 for Sprint in US<br />
|USB<br />
|----<br />
|Sprint U300/300U 4G wireless card [http://support.sprint.com/support/device/Sprint/3G4G_USB_Modem_U300-franklin_u300]<br />
|v4.6 and higher<br />
|C-MOTECH Co, FW301DOWMX, QUALCOMM Patch 33504 <br />
|USB<br />
|----<br />
|Franklin M600 3G/4G wireless card [http://www.franklinwireless.com/image/ebrochure/M600_datasheet_v1.pdf]<br />
|v5.x and higher<br />
|only 3G mode <br />
|MiniPCI-e<br />
|----<br />
|Verizon Express Network PC5220 (AirPrime 5220) <br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|ZTE AC8700 <br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
|ZTE MF620 / MF622 [http://wwwen.zte.com.cn/endata/mobile/UK/UK_Instruction/201011/P020101118724987299606.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|ZTE MF620 / MF622 (3G) [http://wwwen.zte.com.cn/endata/mobile/UK/UK_Instruction/201011/P020101118724987299606.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|ZTE MF100 [http://www.3gmodem.com.hk/ZTE/MF100.html]<br />
|v5.11 and higher<br />
|Set info channel = 1, data channel = 2<br />
|USB<br />
|----<br />
|ZTE MF680 [http://www.3gmodem.com.hk/ZTE/MF680.html]<br />
|v5.4 and higher<br />
|Used by 3 in Sweden. Set data chanel to 1<br />
|USB<br />
|----<br />
|ZTE MF668 [http://wwwen.zte.com.cn/en/products/mobile/mobile_detail_291.jsp?mobileName=MF668]<br />
|v4.5 and higher<br />
|for Rogers Wireless (Canada) Set APN: isp.apn and Info & Data Channel to 1<br />
|USB<br />
|----<br />
|T-Mobile (Germany) Web´n´Walk Box Micro (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Vodafone (Germany) Easybox 2 (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Surfbox Mini (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|E-Plus & Base (Germany) USB Minimodem (Huawei E220) [http://www.huaweidevice.com/worldwide/productFeatures.do?pinfoId=282&directoryId=5008&treeId=582&tab=0]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Huawei E600<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin V640/XV620 [http://www.novatelwireless.com/images/pdf/Merlin_XV620_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel Merlin V620/S620 [http://www.novatelwireless.com/content/pdf/Merlin_V620_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin EX720/V740/X720 [http://www.novatelwireless.com/images/pdf/Merlin_X720_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel Merlin V720/S720/PC720 [http://www.novatelwireless.com/content/pdf/Merlin_PC720_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Novatel Merlin XU870 HSDPA/3G [http://www.novatelwireless.com/images/pdf/Merlin_XU870_DataSheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel X950D [http://www.novatelwireless.com/content/pdf/Merlin_X950D_datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|ExpressCard<br />
|----<br />
|Novatel ES620/ES720/U720/USB720<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel E725/E726 [http://www.novatelwireless.com/content/pdf/Expedite_E725_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Vodafone EU740/Novatel non-Vodafone EU740<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Vodafone K3565/Huawei E160 [http://3g-modem.wetpaint.com/page/Huawei+E160+%28E160G%2C+E160E%2C+E160X%2C+K3565%29]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel EU850D/EU860D/EU870D [http://www.novatelwireless.com/content/pdf/EU850D_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel MC930D/MC950D [http://www.novatelwireless.com/content/pdf/OvationMC950D_datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel MC727/U727 [http://www.novatelwireless.com/content/pdf/Ovation_MC727_Datasheet.pdf]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
|Novatel Expedite EV620 CDMA/EV-DO <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Expedite EU740 HSDPA/3G, Dell Wireless 5500 Mobile/Dell Wireless 5505 Mobile <br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Expedite E720 CDMA/EV-DO<br />
|v3.x and higher<br />
|<br />
|MiniPCI-e<br />
|----<br />
|Novatel Expedite ET620 CDMA/EV-DO<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|----<br />
|Onda H600/ZTE MF330<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
| BP3-USB & BP3-EXT HSDPA<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---- <br />
| ZTE MY 39 (MSM 6500 based) [http://ebookbrowse.com/manual-zte-my39-eng-pdf-d40571716]<br />
|v3.x and higher<br />
|<br />
|PCMCIA<br />
|---- <br />
| Cricket A600<br />
|v3.x and higher<br />
|<br />
|<br />
|---- <br />
| Globetrotter HSDPA Modem Option N.V.<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
| Sony Ericsson MD300<br />
|v3.x and higher<br />
|<br />
|<br />
|----<br />
| ZTE MF 626 [http://3g-modem.wetpaint.com/page/ZTE+MF626]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|----<br />
| ZTE MF 627 [http://3g-modem.wetpaint.com/page/ZTE+MF627]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---<br />
| Pantech / UTStarcom UM175<br />
|v3.x and higher<br />
| <br />
|USB<br />
|---<br />
| Novatel U760 [http://www.novatelwireless.com/index.php?option=com_content&view=article&id=166]<br />
|v3.x and higher<br />
|<br />
|USB<br />
|---<br />
| ZTE K3565-Z [http://3g-modem.wetpaint.com/page/ZTE+K3565-Z+%28Vodafone%29]<br />
|v4.4 and higher<br />
|Revision: BD_P673A2V1.0.0B09 <br />
|USB<br />
|---<br />
| Novatel Expedite EV620 <br />
|v4.5 and higher<br />
|<br />
|MiniPCI-e<br />
|---<br />
| Novatel MC760 VMU [http://www.novatelwireless.com/content/pdf/Datasheet_MC760.pdf]<br />
|v4.5 adn higher<br />
| <br />
|USB<br />
|---<br />
| Franklin Wireless FW300DOWMX<br />
|v4.5 and higher<br />
| <br />
|<br />
|---<br />
| Huawei EC1260<br />
|v4.5 and higher<br />
| <br />
|USB<br />
|---<br />
| Vodafone K3520-Z [http://www.business.vodafone.com/download/getFmlDoc.do?docId=7c3f8af5-9fcf-41c4-8847-d4059a0665f0]<br />
|v4.6 and higher<br />
| <br />
|USB<br />
|---<br />
| Vodafone K3765 [http://www.3gmodem.com.hk/Huawei/K3765.html]<br />
|v4.6 and higher<br />
| <br />
|USB<br />
|---<br />
| Telstra 3G Elite<br />
|v5.x and higher<br />
| <br />
|USB<br />
|---<br />
| Vodafone [http://www.twayf.com/huawei-k4505 Huawei K4505]<br />
|v5.x and higher<br />
| Data-channel=0 Info-channel=3<br />
| USB<br />
|---<br />
| Vertex VW 110<br />
|v5.x and higher<br />
| <br />
|<br />
|---<br />
| ZTE MF112 [http://www.3gmodem.com.hk/ZTE/MF112.html]<br />
|v5.x and higher<br />
| Power issues on mipsbe boards<br />
|USB<br />
|---<br />
| Huawei ET127<br />
|v5.x and higher<br />
| <br />
|3G<br />
|---<br />
| Huawei EC1261<br />
|v5.x and higher<br />
| <br />
|USB<br />
|---<br />
| Huawei E173 [http://3g-modem.wetpaint.com/page/Huawei+E173]<br />
|v5.x and higher<br />
| <br />
|USB<br />
|---<br />
| ZTE MF190 [http://wwwen.zte.com.cn/endata/mobile/info/201102/t20110209_219190.html]<br />
|v5.x and higher<br />
|Data channel=3 and info Channel=1<br />
|USB<br />
|---<br />
|ZTE MF102 [http://wwwen.zte.com.cn/en/products/mobile/mobile_detail_291.jsp?mobileName=ZTE%20MF102]<br />
|v5.x and higher<br />
|Works! Possible that need to change data channel=2 and info channel=2<br />
|USB<br />
|---<br />
|China TeleCom or ZTE AC682<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Option Globetrotter GT380<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Simcom 5220<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Huawei K3770<br />
|v5.x and higher<br />
|<br />
|<br />
|---<br />
|Novatel USB551L (Verizon) [http://www.novatelwireless.com/content/pdf/MC551NVTLDatasheetRev2.pdf]<br />
|v5.9 and higher<br />
|Only 3G support (No LTE support)<br />
|UB<br />
|---<br />
|Novatel Wireless MIFI4510<br />
|<br />
|Not supported<br />
|<br />
|---<br />
|ZTE MC2718 [http://www.headele.com/Datasheet/EVDO/MC2716&MC2718%20Technical%20Specifications%20and%20Hardware%20Design.pdf]<br />
|v5.8 and higher<br />
|Possible data-channel=0 info-channel=1 GPS(NMEA)=4<br />
|MiniPCI-e<br />
|---<br />
|LG-VL600 (Verizon)<br />
|<br />
|Not supported<br />
|<br />
|---<br />
|Huawei EC156 [http://www.tataphoton.com/download/user-manuals/Huawei-EC156-User-Manual.pdf]<br />
|v5.8 and higher<br />
|<br />
|USB<br />
|---<br />
|K3806 [http://vodafone.com/content/dam/vodafone/about/what/devices/mobile_broadband/pdf/vodafonek3806specs.pdf]<br />
|v5.8 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE MF-210V [http://www.smartm2msolutions.com/Recursos/downloads/MF210.pdf]<br />
|v5.9 and higher<br />
|<br />
|MiniPCI-e<br />
|---<br />
|Huawei E398 [http://www.twayf.com/huawei-e398-lte-modem]<br />
|v5.9 and higher<br />
|<br />
|USB<br />
|---<br />
| Huawei E367<br />
|v5.11 and higher<br />
|<br />
| USB<br />
|---<br />
|Huawei EM770 [http://www.arm9.net/datasheet/EM770.pdf]<br />
|v5.11 and higher<br />
|<br />
|MiniPCI-e<br />
|---<br />
|Nokia E52 (Series 60)<br />
|v5.12 and higher<br />
|Set Usb mode to "PC Suite" in phone menu, Baud rate - 115200, Ports - 0/0, APN - internet, no modem init string, Dial number - *99#<br />
|USB<br />
|---<br />
|Nokia 6700 Classic (Series 40)<br />
|v5.12 and higher<br />
|Set Usb mode to "PC Suite" in phone menu<br />
Baud rate - 115200<br />
Ports - 0/0<br />
APN - internet<br />
Modem init string - ATZ, Dial number - *99#<br />
<br />
Phone is charged up through the USB port<br />
|USB<br />
|---<br />
|Alcatel X220S [http://www.alcatelonetouch.com/global-en/products/mobile_broadband/ot-x220.html]<br />
|v5.13 and higher<br />
|<br />
|USB<br />
|---<br />
|MO835UP <br />
|v5.14 and higher<br />
|<br />
|USB<br />
|---<br />
|Nokia Datacard CS-11 & CS-15 <br />
|v5.14 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE MF821<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Huawei K4510 [http://www.vodafone.com/content/dam/vodafone/about/what/devices/mobile_broadband/pdf/vodafonek4510k4511specs.pdf]<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Huawei E173s<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Option3G Mini-PCI model GTM661W<br />
|<br />
|Not supported<br />
|USB<br />
|---<br />
|Option 225<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE AC682<br />
|v5.15 and higher<br />
| <br />
|USB<br />
|---<br />
|ZTE AX320<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|ZTE MF 652<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Vodafone Huawei K-4605<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|Huawei E353<br />
|v5.15 and higher<br />
|<br />
|USB<br />
|---<br />
|CELOT CT-680<br />
|v5.16 and higher<br />
|<br />
|USB<br />
|---<br />
|}<br />
<br />
<br />
<br />
<br />
<br />
<br />
'''*''' - Currently MikroTik RouterOS works with PPP 3G modems over serial interfaces, 4G modems with IP drivers are not supported.<br />
<br />
=='''4G LTE cards'''==<br />
<br />
{| border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Tested RouterOS version !! Comments !! Format<br />
|-<br />
|---<br />
|BandRich C501 [http://www.bandrich.com/Data-Card_C500.html]<br />
|v5.12<br />
|Configure under the new "/interface lte" menu<br />
|USB<br />
|}<br />
<br />
=='''Memory cards'''==<br />
<br />
NB! New flash cards need always formatting!<br />
<br />
Legend: <br />
<br />
*V - works<br />
*X - doesn't work<br />
*? - not tested<br />
*NA - not available for this RB<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Type !! RB600 !! RB1000 !! RB433AH !! RB450G !! R493G<br />
|----<br />
|PQI 4GB 120x HiSpeed || CF || '''X''' || ? || NA || ? || ?<br />
|----<br />
|2GB Transcend 133x || CF || X || ? || NA || ? || ?<br />
|----<br />
|2GB Kingston 133x (Elite Pro, code CF/2GB-S2)|| CF || V || ? || NA || ? || ?<br />
|----<br />
|4GB Kingston 133x (Elite Pro)|| CF || ? || V || NA || ? || ?<br />
|----<br />
|4GB Kingston CF/4GBIN || CF || '''X''' || ? || NA || ? || ?<br />
|----<br />
|8GB A-Data Speedy G08GNMC7B0095|| CF || V || V || NA || ? || ?<br />
|----<br />
|16GB A-Data Speedy || CF || V || V || NA || ? || ?<br />
|----<br />
|4GB Apacer Photo Steno IV 300X || CF || '''X''' || '''X''' || NA || ? || ?<br />
|----<br />
|1GB Sandisk Ultra II BB05024GA|| CF || V || V || NA || ? || ?<br />
|----<br />
|2GB Sandisk Ultra II || CF || ? || V || NA || ? || ?<br />
|----<br />
|8GB Sandisk Ultra II || CF || ? || V || NA || ? || ?<br />
|----<br />
|8GB SanDisk Extreme III (200X,30MB/s) || CF || ? || V || NA || ? || ?<br />
|----<br />
|2.5GB Seagate ST1 (ST625211CF) || CF microdrive|| V || V || NA || ? || ?<br />
|----<br />
|8GB Seagate ST1 || CF microdrive || V || V || NA || ? || ?<br />
|----<br />
|64MB Nokia || microSD || NA || NA ||? || V || ?<br />
|----<br />
|512MB Kingston || microSD || NA || NA || V || ? || ?<br />
|----<br />
|1GB Apacer || microSD || NA || NA || V || ? || ?<br />
|----<br />
|1GB Kingston (SDC/1GB) || microSD || NA || NA || ? || X|| ?<br />
|----<br />
|2GB Kingston || microSD || NA || NA || '''X'''|| [[:Image:Kingston_rubbish.jpg | '''X''']] || ?<br />
|----<br />
|2GB Traxdata || microSD || NA || NA ||? || [[:Image:Traxdata_microSD_working.jpg | '''V''']] || ?<br />
|----<br />
|4GB Apacer SDHC (class 6) || microSD|| NA || NA || V || X || ?<br />
|----<br />
|4GB Axiz || microSD|| NA || NA || V || ? || ?<br />
|----<br />
|4GB Kingston || microSD || NA || NA || V || ? || ?<br />
|----<br />
|4GB Kingston SDHC (C04G JAPAN class 4) || microSD || NA || NA || V|| ? || ?<br />
|----<br />
|4GB Maxell SDHC (class 2) P-series || microSD || NA || NA || ?|| ? || V<br />
|----<br />
|4GB Transcend SDHC || microSD || NA || NA || V|| ? || ?<br />
|----<br />
|4GB Sandisk Mobile Ultra Micro SDHC (with card reader) || microSD || NA || NA || ? || V || ?<br />
|----<br />
|8GB Sandisk SDHC (0733702482DLE) || microSD || NA || NA || V || V || ?<br />
|----<br />
|8GB Sandisk Mobile microSDHC (SDSDQ-8192-A11M) || microSD || NA || NA || ? || V|| ?<br />
|----<br />
|8GB Sandisk Mobile Ultra SDHC (Class 6) || microSD || NA || NA || ?|| V || ?<br />
|----<br />
|8GB Kingston SDHC (Class 4) || microSD || NA || NA || V|| X || ?<br />
|----<br />
|8GB ADATA micro SDHC (AUSDH8GCL6) (Class 6) || microSD || NA || NA || ? || V || ?<br />
|----<br />
|16GB Sandisk micro SDHC (SDSDQ-16384-P36M) class 2|| microSD || NA || NA || NA|| X|| ?<br />
|----<br />
|16GB Sandisk micro SDHC (0835B03279DQ) class 2|| microSD || NA || NA || V|| V|| ?<br />
|----<br />
|2GB Sandisk micro SDHC class 2|| microSD || NA || NA || NA|| X|| V<br />
|----<br />
|4GB Sandisk Mobile microSDHC (SDSDQM-004G-B35S) class 4|| microSD || NA || NA || ?|| X|| X<br />
|}<br />
<br />
Note: Pushing the "Kingston SDHC 8GB card" all the way into the socket caused the card not to work properly! It had to be pulled out ~1mm for it to work!<br />
<br />
==802.11a/b/g wireless cards==<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! Platform !!ROS!! Result<br />
|----<br />
|TechnicLan [http://www.techniclan.com/Wireless_mPCI_TMP-5414A_11abg_108Mbps_Atheros_solution,p,74.html TMP-5414A]|| miniPCI ||All RouterBOARDs||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=23 WLM54AG-20]|| miniPCI ||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=25 WLM54A-26]|| miniPCI ||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|----<br />
| SparkLAN WMIA-165G||miniPCI||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
| SparkLAN WMIA-166AG||miniPCI||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
| SparkLAN WMIA-166AGH||miniPCI||RB1xx / RB3xx / RB4xx / RB5xx / RB6xx / x86||2.9 / 3.x / 4.x||Perfect, Stable<br />
|----<br />
|Alfa AWPCI 085 H||miniPCI||RB1xx/RB333/RB4xx/x86||2.9&3.x||All just perfect<br />
|----<br />
|TP-Link TL-WN550/551||PCI||x86||2.9&3.x||Perfect 19dB rated, stable at 21<br />
|----<br />
|TP-Link TL-WN650/651||PCI||x86||2.9&3.x||Perfect 19dB rated, stable at 21. Unstable with compression activated<br />
|----<br />
|D-Link AG530 a/b/g (both rev.A1 and A2)||PCI||x86||2.9&3.x||Perfect. Works perfect, in both 2.4 and 5.x GHz<br />
|----<br />
|D-Link DWL-G510||PCI||x86||only 2.9.x tested||Perfect. Tested Rev A1<br />
|----<br />
|D-Link DWL-G520||PCI||x86||2.9.x & 3.x||Works well.<br />
|----<br />
|D-Link DWL-G520+A/RaLink 2591 Chipset||PCI||x86||4.9|| NOT Work!<br />
|----<br />
|Gigabyte b/g GN-WI01GT||miniPCI-e||x86||3.x||Works also in RouterBOARDs with miniPCI-e slot<br />
|----<br />
|Senao NL-2511CD EXT2||PCMCIA||x86&rb230||only 2.9x tested||Perfect. Just about the most sensitive card i used, in the good sense. Only 11b. <br />
|----<br />
|Planet WL-8310||PCI||x86||only 2.9.x tested||Perfect. Stability.<br />
|----<br />
|Netgear WG311T 108||PCI||x86||only 2.9x tested||Perfect. stability<br />
|----<br />
|SMC SMCWPCIT-G ||PCI||x86||3.x tested||Perfect on A/B/G. <br />
|----<br />
|Wistron DCMA-81 || miniPCI ||x86,rb||2.9.xx, 3.xx||Perfect on A/B/G with or without compression.<br />
|----<br />
|Wistron DCMA-82|| miniPCI ||rb||3.xx||Works on some RB, but on 2/3 of my RB433 it causes the board to reboot when enabled. Many other people have had similar experiences. Not recommended. Maybe OK on 133<br />
|----<br />
|Senao NMP-8602|| miniPCI ||x86&rb411||2.9x,3.x tested||Perfect on a/b/g<br />
|----<br />
|Dbii [http://dbii.com/f20.html F20]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on B/G, too thick for 3 in rb433<br />
|----<br />
|Dbii [http://dbii.com/f50.html F50]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on A, too thick for 3 in rb433<br />
|----<br />
|Dbii [http://www.dbii.com/f20-PRO.html F20-PRO]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on B/G, too thick for 3 in rb433<br />
|----<br />
|Dbii [http://www.dbii.com/f50-PRO.html F50-PRO]|| miniPCI ||RB411 & RB433||3.x tested||Perfect on A, too thick for 3 in rb433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/xr2.php XR2]|| miniPCI ||RB433||3.x||works as advertised, too thick for 3 in rb433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/xr5.php XR5]|| miniPCI ||RB433, x86||3.x||works as advertised, too thick for 3 in rb433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/sr9.php SR9]|| miniPCI ||RB433||3.x||works as advertised, thin enough to load 3 in RB433<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/xr9.php XR9]|| miniPCI ||RB411 & RB433||3.x||works as advertised, thin enough to place cards above, but antenna port may contact cards below<br />
|----<br />
|Valemount [http://www.staros.com/documentation/KXS30SG%20Sell%20Sheet.pdf KXS30SG]||miniPCI||RB433||3.2 & 4.2 tested||B/G only, no A. Big heat sink means card should be installed on highest mount when other cards being used. High power consumption can cause power problems, otherwise works perfectly. <br />
|----<br />
|Zcomax [http://www.zcomax.cz/Xg650.aspx XG-650]|| miniPCI ||RB112 & RB433||4.2 & 4.6||Not working (driver doesnt work / exist). It has a TI TNETW1130GVF chipset.<br />
|----<br />
|AR5BMB5 || miniPCI ||RB411,x86||3.xx, 4.3||Not working. Atheros chipset.<br />
|}<br />
<br />
=== 802.11n wireless cards ===<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! ROS!! Result<br />
|----<br />
|[http://store.dcsindo.com/interfaces/wireless-minipci/wmia-198n.html SparkLAN WMIA-198N]|| miniPCI ||4x, 5x||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=96 WLM200N5-23]|| miniPCI ||4.0b3||Perfect, Stable<br />
|----<br />
|----<br />
|Compex [http://www.compex.com.sg/fullDescription.aspx?pID=32 WLM200NX]|| miniPCI ||4.0b3||Perfect, Stable<br />
|----<br />
|----<br />
|Dbii [http://dbii.com/f52N-PRO.html F52N-PRO]|| miniPCI ||5.1||Stable<br />
|----<br />
|----<br />
|RouterBOARD [http://www.routerboard.com/prices.html R2N]|| miniPCI ||4.0b3||works<br />
|----<br />
|RouterBOARD [http://www.routerboard.com/prices.html R52N]|| miniPCI ||4.0b3||works<br />
|----<br />
|TP-Link Wireless N (2T2R)|| miniPCI ||4.0b3||works<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/sr71a.php SR71-A]|| miniPCI ||4.0b3||works<br />
|----<br />
|Ubiquiti [http://www.ubnt.com/products/sr71a.php SR71-A]|| miniPCI ||4.0b3||works<br />
|}<br />
<br />
=== USB wireless cards ===<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! ROS !! Result<br />
|----<br />
|802 b/g/n AR9271 || USB || 5.0rc4 || works<br />
|----<br />
|802 b/g/n AR9271 Ubiquiti WiFiStation || USB || 5.8 x86 || works on N but causes reboot on G<br />
|----<br />
|802 b/g/n AR9271 ALFA AWUS036NHA || USB || 5.14 x86 || works<br />
|----<br />
|802 b/g/n AR9170 NETGEAR WN111v2 || USB || 5.16 x86 || Don't recognize<br />
|}<br />
<br />
==T1/E1==<br />
<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Form factor !! Platform !!ROS!! Result<br />
|----<br />
|Farsite FarSync TE1||PCI||x86||3.15||supported<br />
|----<br />
|}<br />
<br />
''Note: Since v3.15 RouterOS doesn't support any Sync/T1/E1 cards except select Farsite models''<br />
<br />
==GPS==<br />
<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Model !! Connection !! Platform !!ROS!! Result<br />
|----<br />
|EXAMPLE||USB||x86||3.30||supported<br />
|----<br />
|}<br />
<br />
==Storage controllers (SAS/SCSI) ==<br />
<br />
Post only tests since RouterOS v5beta5<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !! Motherboard !! RouterOS !! Works !! Type<br />
|----<br />
|HP||Smart Array E200i||x86||v5rc1||No || SCSI<br />
|----<br />
|3ware||3w-9xxx||x86||v5rc8||Yes || SCSI<br />
|----<br />
|Areca||arcmsr ||x86||v5rc8||Yes || SCSI<br />
|----<br />
|Megaraid||Megaraid (some Dell servers)||x86||v5rc8||Yes || SCSI<br />
|}<br />
<br />
== LCD panels==<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !! Motherboard !! RouterOS !! Works / Doesn't <br />
|----<br />
|Crystalfontz||CFA-633v1.5||x86||v5RC10||[[Crystalfontz_CFA-633|Works]]<br />
|----<br />
|Crystalfontz||CFA-633v1.3||x86||v5RC7-RC10||[[Crystalfontz_CFA-633|Didn't work]]<br />
|---<br />
|}<br />
<br />
==USB storage==<br />
<br />
{{Note | USB storage device that does not require special drivers or is compatible to work with generic USB storage drivers will work. Devices include external hard drives, USB flash drives}}<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !!Works / Doesn't <br />
|---<br />
|generic||USB flash drive||Works<br />
|---<br />
|Kingston||DataTraveler 2GB||Works<br />
|}<br />
<br />
==SFP modules==<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !! Rate !! Connector/Cable type !! Wavelength !! Tested with !! Works / Doesn't <br />
|---<br />
|Finisair || FCLF-8521-3 || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Finisair || FCLF-8521-3-MD || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Unica || SFP-1.25G-T || 1000M || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Dell || FTLX8571D3BCL || 1,25G || LC, MM || 850 || RB2011LS-IN || Works!<br />
|---<br />
|Unica || GP-3124-L2CD-C || 1,25G || LC, MM || 1310 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-SFP-T || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-WDM-0210BSD || 1,25G ||Bi-Di SC, SM || 1550/1310 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-WDM-0210ASD || 1,25G || Bi-Di SC, SM || 1310/1550 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-SFP-0310D || 1,25G || LC, MM || 1310 || RB2011LS-IN || Works!<br />
|---<br />
|6COM || 6C-SFP-0301D || 1,25G || LC, MM || 850 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSP-T(10/100/1000) || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSPL-53-BX || 1,25G || Bi-Di LC, MM|| 1550/1310 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSPL-35-BX || 1,25G || Bi-Di LC, MM|| 1310/1550 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSP -LX-SM || 1,25G || LC, MM/SM|| 1310 || RB2011LS-IN || Works!<br />
|---<br />
|Ingellen || INSP-SX-MM || 1,25G || LC, MM || 850 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGT-R1T4-05I1 || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-37А4-0531 || 1,25G || Bi-Di LC, MM|| 1550/1310 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-16А4-0531 || 1,25G || Bi-Di LC, MM|| 1310/1550 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-1354-0531 || 1,25G || LC, MM|| 1310 || RB2011LS-IN || Works!<br />
|---<br />
|AXCEN || AXGD-5854-0511 || 1,25G || LC, MM|| 850 || RB2011LS-IN || Works!<br />
|---<br />
|MikroTik || RB SFP3401 || 10/100/1000 || RJ45, Cat6 || - || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP5602D-53 || 155M~2.63G || Bi-Di LC, MM|| 1550/1310 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP5602D-35 || 155M~2.63G || Bi-Di LC, MM|| 1310/1550 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP3420D || 1,25G || LC, MM|| 1310 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
|MikroTik || RB SFP3903D || 10G || LC, MM|| 850 || RB2011LS-IN || Works. Available in Q3!<br />
|---<br />
<br />
|}<br />
<br />
==USB serial adapters==<br />
<br />
{{Note| when USB serial port is connected RouterOS might attach serial console on the port. Before using it for something else, disable the console on the interface}}<br />
<br />
{|border="1" class="wikitable collapsible sortable" style="text-align:center"<br />
! Brand !! Model !!Works / Doesn't <br />
|---<br />
| ||USB U209-000-R Serial-Port||Works<br />
|}<br />
<br />
==USB Ethernet==<br />
<br />
{{Note | see if device works with one of these linux kernel modules. If yes, it will be possible to use it on RouterOS}}<br />
<br />
RouterOS on x86 have these modules enabled<br />
*USB_PEGASUS<br />
*USB_RTL8150<br />
*USB_USBNET<br />
*USB_NET_AX8817X<br />
*USB_NET_CDCETHER<br />
*USB_HSO<br />
<br />
RouterOS on mips have these modules enabled:<br />
*USB_NET_MCS7830<br />
*USB_NET_AX8817X<br />
*USB_NET_CDCETHER<br />
*USB_HSO<br />
*USB_USBNET<br />
<br />
AX88178 (USB2.0 Gigabit Ethernet) recognized but not working.<br />
<br />
[[Category:Hardware]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Queues_-_PCQ_Examples&diff=23193Manual:Queues - PCQ Examples2012-02-22T12:46:01Z<p>Megis: </p>
<hr />
<div>Per Connection Queue (PCQ) is a queuing discipline that can be used to dynamically equalize or shape traffic for multiple users, using little administration. It is possible to divide PCQ scenarios into three major groups: equal bandwidth for a number of users, certain bandwidth equal distribution between users, unknown bandwidth equal distribution between users.<br />
<br />
=== Equal Bandwidth for a Number of Users ===<br />
<br />
Use PCQ type queue when you need to equalize the bandwidth [and set max limit] for a number of users. We will set the 64kbps download and 32kbps upload limits.<br />
<br />
[[Image:PCQ.png]]<br />
<br />
There are two ways how to make this: using mangle and queue trees, or, using simple queues.<br />
<br />
1. Mark all packets with packet-marks upload/download: (lets constider thet ether1-LAN is public interface to the Internet and ether2-LAN is local interface where clients are connected<br />
<br />
/ip firewall mangle add chain=prerouting action=mark-packet in-interface=ether1-LAN new-packet-mark=client_upload<br />
/ip firewall mangle add chain=prerouting action=mark-packet in-interface=ether2-WAN new-packet-mark=client_download<br />
<br />
2. Setup two PCQ queue types - one for download and one for upload. ''dst-address'' is classifier for user's download traffic, ''src-address'' for upload traffic:<br />
<br />
/queue type add name="PCQ_download" kind=pcq pcq-rate=64000 pcq-classifier=dst-address<br />
/queue type add name="PCQ_upload" kind=pcq pcq-rate=32000 pcq-classifier=src-address<br />
<br />
<br />
3. Finally, two queue rules are required, one for download and one for upload:<br />
<br />
/queue tree add parent=global-in queue=PCQ_download packet-mark=client_download<br />
/queue tree add parent=global-out queue=PCQ_upload packet-mark=client_upload<br />
<br />
If you don't like using mangle and queue trees, you can skip step 1, do step 2, and step 3 would be to create one simple queue as shown here:<br />
<br />
/queue simple add target-addresses=192.168.0.0/24 queue=PCQ_upload/PCQ_download packet-marks=client_download,client_upload <br />
<br />
=== Certain Bandwidth Equal Distribution between Users===<br />
=== Unknown Bandwidth Equal Distribution between Users===<br />
<br />
== See Also ==<br />
<br />
* [[PCQ]]<br />
<br />
[[Category:Manual|QueuesPCQexapmles]]<br />
[[Category:QoS|QueuesPCQexapmles]]<br />
[[Category:Examples|QueuesPCQexapmles]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Queues_-_PCQ_Examples&diff=23192Manual:Queues - PCQ Examples2012-02-22T12:45:23Z<p>Megis: </p>
<hr />
<div>Per Connection Queue (PCQ) is a queuing discipline that can be used to dynamically equalize or shape traffic for multiple users, using little administration. It is possible to divide PCQ scenarios into three major groups: equal bandwidth for a number of users, certain bandwidth equal distribution between users, unknown bandwidth equal distribution between users.<br />
<br />
=== Equal Bandwidth for a Number of Users ===<br />
<br />
Use PCQ type queue when you need to equalize the bandwidth [and set max limit] for a number of users. We will set the 64kbps download and 32kbps upload limits.<br />
<br />
[[Image:PCQ.png]]<br />
<br />
There are two ways how to make this: using mangle and queue trees, or, using simple queues.<br />
<br />
1. Mark all packets with packet-marks upload/download: (lets constider thet ether1-LAN is public interface to the Internet and ether2-LAN is local interface where clients are connected<br />
<br />
/ip firewall mangle add chain=prerouting action=mark-packet in-interface=ether1-LAN new-packet-mark=client_upload<br />
/ip firewall mangle add chain=prerouting action=mark-packet in-interface=ether2-WAN new-packet-mark=client_download<br />
<br />
2. Setup two PCQ queue types - one for download and one for upload. ''dst-address'' is classifier for user's download traffic, ''src-address'' for upload traffic:<br />
<br />
/queue type add name="PCQ_download" kind=pcq pcq-rate=64000 pcq-classifier=dst-address<br />
/queue type add name="PCQ_upload" kind=pcq pcq-rate=32000 pcq-classifier=src-address<br />
<br />
<br />
3. Finally, two queue rules are required, one for download and one for upload:<br />
<br />
/queue tree add parent=global-in queue=PCQ_download packet-mark=client_download<br />
/queue tree add parent=global-out queue=PCQ_upload packet-mark=client_upload<br />
<br />
If you don't like using mangle and queue trees, you can skip step 1, do step 2, and step 3 would be to create one simple queue as shown here:<br />
<br />
/queue simple add target-addresses=192.168.0.0/24 queue=PCQ_upload/PCQ_download packet-marks=client_download,client_upload <br />
<br />
=== Certain Bandwidth Equal Distribution between Users===<br />
=== Unknown Bandwidth Equal Distribution between Users===<br />
<br />
== See Also ==<br />
<br />
* [[PCQ]]<br />
<br />
[[Category:Manual|QueuesPCQexapmles]]<br />
[[Category:QoS|QueuesPCQexapmles]]<br />
[[Category:Examples|QueuesPCQexapmles]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Queues_-_PCQ_Examples&diff=23191Manual:Queues - PCQ Examples2012-02-22T12:44:56Z<p>Megis: </p>
<hr />
<div>Per Connection Queue (PCQ) is a queuing discipline that can be used to dynamically equalize or shape traffic for multiple users, using little administration. It is possible to divide PCQ scenarios into three major groups: equal bandwidth for a number of users, certain bandwidth equal distribution between users, unknown bandwidth equal distribution between users.<br />
<br />
=== Equal Bandwidth for a Number of Users ===<br />
<br />
Use PCQ type queue when you need to equalize the bandwidth [and set max limit] for a number of users. We will set the 64kbps download and 32kbps upload limits.<br />
<br />
[[Image:PCQ.png]]<br />
<br />
There are two ways how to make this: using mangle and queue trees, or, using simple queues.<br />
<br />
1. Mark all packets with packet-marks upload/download: (lets constider thet ether1-LAN is public interface to the Internet and ether2-LAN is local interface where clients are connected<br />
<br />
/ip firewall mangle <br />
add chain=prerouting action=mark-packet in-interface=ether1-LAN new-packet-mark=client_upload<br />
add chain=prerouting action=mark-packet in-interface=ether2-WAN new-packet-mark=client_download<br />
<br />
2. Setup two PCQ queue types - one for download and one for upload. ''dst-address'' is classifier for user's download traffic, ''src-address'' for upload traffic:<br />
<br />
/queue type add name="PCQ_download" kind=pcq pcq-rate=64000 pcq-classifier=dst-address<br />
/queue type add name="PCQ_upload" kind=pcq pcq-rate=32000 pcq-classifier=src-address<br />
<br />
<br />
3. Finally, two queue rules are required, one for download and one for upload:<br />
<br />
/queue tree add parent=global-in queue=PCQ_download packet-mark=client_download<br />
/queue tree add parent=global-out queue=PCQ_upload packet-mark=client_upload<br />
<br />
If you don't like using mangle and queue trees, you can skip step 1, do step 2, and step 3 would be to create one simple queue as shown here:<br />
<br />
/queue simple add target-addresses=192.168.0.0/24 queue=PCQ_upload/PCQ_download packet-marks=client_download,client_upload <br />
<br />
=== Certain Bandwidth Equal Distribution between Users===<br />
=== Unknown Bandwidth Equal Distribution between Users===<br />
<br />
== See Also ==<br />
<br />
* [[PCQ]]<br />
<br />
[[Category:Manual|QueuesPCQexapmles]]<br />
[[Category:QoS|QueuesPCQexapmles]]<br />
[[Category:Examples|QueuesPCQexapmles]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Simple_TE&diff=22150Manual:Simple TE2011-10-03T11:37:24Z<p>Megis: </p>
<hr />
<div>==Summary==<br />
<br />
This article shows how to simply create traffic engineering tunnels using both dynamic and static tunnel paths.It also shows how to steer traffic over the tunnel.<br />
<br />
<br />
==Network Layout==<br />
<br />
We will create a network consisting of four routers connected in diamond shape as illustrated in diagram below.<br />
<br />
[[File:Simple-te.png | 700px | center]]<br />
<br />
Each router is connected to neighboring router using /30 network and each of them have unique loopback address form 10.255.0.x network. Loopback addresses will be used as tunnel source and destination.<br />
<br />
The goal is to interconnect two LAN segments (Lan1, Lan2) using TE tunnels in the way that:<br />
* traffic in direction from LAN1 to LAN2 goes over path through R2<br />
* traffic in direction from LAN2 to LAN1 goes over path through R4<br />
<br />
==Router Configurations==<br />
<br />
===Connectivity between routers and Loopback addresses===<br />
<br />
'''R1'''<br />
<pre><br />
/system identity set name=R1<br />
<br />
/interface bridge add name=Loopback<br />
<br />
/ip address<br />
add address=192.168.33.1/30 interface=ether1<br />
add address=192.168.33.14/30 interface=ether2<br />
add address=192.168.10.1/24 interface=ether3<br />
add address=10.255.0.1/32 interface=Loopback<br />
</pre><br />
<br />
'''R2'''<br />
<pre><br />
/system identity set name=R2<br />
<br />
/interface bridge add name=Loopback<br />
<br />
/ip address<br />
add address=192.168.33.2/30 interface=ether1<br />
add address=192.168.33.5/30 interface=ether2<br />
add address=10.255.0.2/32 interface=Loopback<br />
</pre><br />
<br />
<br />
'''R3'''<br />
<pre><br />
/system identity set name=R3<br />
<br />
/interface bridge add name=Loopback<br />
<br />
/ip address<br />
add address=192.168.33.6/30 interface=ether1<br />
add address=192.168.33.9/30 interface=ether2<br />
add address=192.168.20.1/24 interface=ether3<br />
add address=10.255.0.3/32 interface=Loopback<br />
</pre><br />
<br />
'''R4'''<br />
<pre><br />
/system identity set name=R4<br />
<br />
/interface bridge add name=Loopback<br />
<br />
/ip address<br />
add address=192.168.33.10/30 interface=ether1<br />
add address=192.168.33.13/30 interface=ether2<br />
add address=10.255.0.4/32 interface=Loopback<br />
</pre><br />
<br />
<br />
===Loopback address reachability and CSPF setup===<br />
<br />
In this setup we will use OSPF dynamic routing protocol to distribute routing information between routers. To successfully complete the setup we need loopback reachability information on every router.<br />
<br />
CSPF will also be configured (extension of OSPF) to carry TE reservation information. <br />
<br />
'''R1'''<br />
<pre><br />
/routing ospf instance<br />
set default router-id=10.255.0.1 mpls-te-area=backbone mpls-te-router-id=Loopback<br />
<br />
/routing ospf network<br />
add network=192.168.33.0/24 area=backbone<br />
add network=10.255.0.1/32 area=backbone<br />
</pre><br />
<br />
'''R2'''<br />
<pre><br />
/routing ospf instance<br />
set default router-id=10.255.0.2 mpls-te-area=backbone mpls-te-router-id=Loopback<br />
<br />
/routing ospf network<br />
add network=192.168.33.0/24 area=backbone<br />
add network=10.255.0.2/32 area=backbone<br />
</pre><br />
<br />
'''R3'''<br />
<pre><br />
/routing ospf instance<br />
set default router-id=10.255.0.3 mpls-te-area=backbone mpls-te-router-id=Loopback<br />
<br />
/routing ospf network<br />
add network=192.168.33.0/24 area=backbone<br />
add network=10.255.0.3/32 area=backbone<br />
</pre><br />
<br />
'''R4'''<br />
<pre><br />
/routing ospf instance<br />
set default router-id=10.255.0.4 mpls-te-area=backbone mpls-te-router-id=Loopback<br />
<br />
/routing ospf network<br />
add network=192.168.33.0/24 area=backbone<br />
add network=10.255.0.4/32 area=backbone<br />
</pre><br />
<br />
<br />
After OSPF is set up verify that we have correct routing information in routing table of each router:<br />
<pre><br />
[admin@R1] /ip route> print <br />
Flags: X - disabled, A - active, D - dynamic, <br />
C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, <br />
B - blackhole, U - unreachable, P - prohibit <br />
# DST-ADDRESS PREF-SRC GATEWAY DISTANCE<br />
0 ADS 0.0.0.0/0 10.5.101.1 1<br />
1 ADC 10.255.0.1/32 10.255.0.1 lo 0<br />
2 ADo 10.255.0.2/32 192.168.33.2 110<br />
3 ADo 10.255.0.3/32 192.168.33.2 110<br />
192.168.33.13 <br />
4 ADo 10.255.0.4/32 192.168.33.13 110<br />
5 ADC 192.168.10.0/30 192.168.10.1 ether3 0<br />
6 ADC 192.168.33.0/30 192.168.33.1 ether1 0<br />
7 ADo 192.168.33.4/30 192.168.33.2 110<br />
8 ADo 192.168.33.8/30 192.168.33.13 110<br />
9 ADC 192.168.33.12/30 192.168.33.14 ether2 0<br />
<br />
</pre><br />
<br />
===Setting Resource Reservation===<br />
<br />
Next step is to set up TE resource for every interface on which we might want to run TE tunnel.<br />
<br />
Configuration on all the routers are the same:<br />
<pre><br />
/mpls traffic-eng interface<br />
add interface=ether1 bandwidth=10Mbps<br />
add interface=ether2 bandwidth=10Mbps<br />
</pre><br />
<br />
Since we are not using real bandwidth limitation on the tunnels in this example, bandwidth parameter is only used for administrative purposes and can be any value (it does not represent how much bandwidth will actually flow through the interface).<br />
<br />
===TE tunnel setup===<br />
<br />
Since our primary goal is to strictly forward traffic over specific path we will use static path configuration as primary, and dynamic (CSPF) as secondary path if primary fails.<br />
<br />
'''R1'''<br />
<pre><br />
/mpls traffic-eng tunnel-path<br />
add name=dyn use-cspf=yes<br />
add name=tun-first-link use-cspf=no \<br />
hops=192.168.33.2:strict,192.168.33.5:strict,192.168.33.6:strict<br />
<br />
/interface traffic-eng<br />
add bandwidth=5Mbps name=TE-to-R3 to-address=10.255.0.3 primary-path=tun-first-link \<br />
secondary-paths=dyn record-route=yes from-address=10.255.0.1<br />
</pre><br />
<br />
<br />
'''R3'''<br />
<pre><br />
/mpls traffic-eng tunnel-path<br />
add name=dyn use-cspf=yes<br />
add name=tun-second-link use-cspf=no \<br />
hops=192.168.33.10:strict,192.168.33.13:strict,192.168.33.14:strict<br />
<br />
/interface traffic-eng<br />
add bandwidth=5Mbps name=TE-to-R1 to-address=10.255.0.1 primary-path=tun-second-link \<br />
secondary-paths=dyn record-route=yes from-address=10.255.0.3<br />
</pre><br />
<br />
<br />
'''Verify that TE tunnels are working'''<br />
<pre><br />
<br />
[admin@R1] /interface traffic-eng> monitor 0<br />
tunnel-id: 14<br />
primary-path-state: established<br />
primary-path: tun-first-link<br />
secondary-path-state: not-necessary<br />
active-path: tun-first-link<br />
active-lspid: 1<br />
active-label: 39<br />
explicit-route: S:192.168.33.2/32,S:192.168.33.5/32,S:192.168.33.6/32<br />
reserved-bandwidth: 5.0Mbps<br />
</pre><br />
<br />
Notice that running router will show assigned MPLS lables, whole tunnel path and reserved bandwidth.<br />
Reserved resources also can be monitored on each router:<br />
<pre><br />
[admin@R1] /mpls traffic-eng> path-state print <br />
Flags: L - locally-originated, E - egress, F - forwarding, P - sending-path, <br />
R - sending-resv <br />
# SRC DST BANDWIDTH OUT.. OUT-NEXT-HOP <br />
0 LFP 10.255.0.1:1 10.255.0.3:15 5.0Mbps eth.. 192.168.33.2 <br />
1 E R 10.255.0.3:1 10.255.0.1:8 5.0Mbps<br />
[admin@R1] /mpls traffic-eng> resv-state print <br />
Flags: E - egress, A - active, N - non-output, S - shared <br />
# SRC DST BANDWIDTH LABEL INT...<br />
0 AS 10.255.0.1:1 10.255.0.3:15 5.0Mbps 41 ether1<br />
[admin@R1] /mpls traffic-eng> <br />
[admin@R1] /mpls traffic-eng> interface print <br />
Flags: X - disabled, I - invalid <br />
# INTERFACE BANDWIDTH TE-METRIC REMAINING-BW<br />
0 ether1 10Mbps 1 5.0Mbps<br />
1 ether2 10Mbps 1 10.0Mbp<br />
</pre><br />
<br />
Notice that remaining bandwidth on interface decreased. It means that if multiple tunnels are created and whole bandwidth on that particular interface is used, then tunnel will try to look for different path.<br />
<br />
{{ Note | TE tunnels are unidirectional, meaning that tunnel may be running in one direction but fail in another direction if whole resources are reserved}}<br />
<br />
<br />
===Route Traffic over TE===<br />
To route LAN traffic over TE tunnel we will assign address 10.99.99.1/30 and 10.99.99.2/30 to each tunnel end.<br />
<br />
'''R1'''<br />
<pre><br />
/ip address add address=10.99.99.1/30 interface=TE-to-R3<br />
<br />
/ip route add dst-address=192.168.20.0/24 gateway=10.99.99.2<br />
</pre><br />
<br />
'''R3'''<br />
<pre><br />
/ip address add address=10.99.99.2/30 interface=TE-to-R1<br />
<br />
/ip route add dst-address=192.168.10.0/24 gateway=10.99.99.1<br />
</pre><br />
<br />
To verify if traffic is actually going over TE tunnel and is label switched we can run traceroute:<br />
<pre><br />
[admin@R1] /ip address> /tool traceroute 10.99.99.1<br />
# ADDRESS RT1 RT2 RT3 STATUS <br />
1 192.168.33.2 2ms 1ms 1ms <MPLS:L=41,E=0> <br />
2 10.99.99.1 3ms 1ms 1ms <br />
</pre><br />
<br />
As you can see traceroute recorded MPLS label in the path.<br />
<br />
Congratulations our setup works.<br />
<br />
==Failover Testing==<br />
<br />
Lets consider that router R4 went down, and whole traffic needs to be switched over R2.<br />
<br />
[[File: Simple-te-failover.png| 700px | center]]<br />
<br />
Traffic engineering does not switch paths automatically. If we use dynamic path then path relies on OSPF routing information and is recalculated whenever one of the link fails.<br />
In case of static primary paths as in our case, we need to re-optimize the tunnel. It can be done in two ways:<br />
* manually - which is not what we need<br />
* automatically - at specific interval<br />
<br />
<br />
To set up path re-optimization we need to specify interval.<br />
<br />
'''R1'''<br />
<pre><br />
/interface trafic-eng set TE-to-R3 reoptimize-interval=5s <br />
</pre><br />
<br />
'''R3'''<br />
<pre><br />
/interface trafic-eng set TE-to-R1 reoptimize-interval=5s <br />
</pre><br />
<br />
After a while tunnel will switch paths do secondary<br />
<pre><br />
[admin@R3] /interface traffic-eng> monitor 0<br />
tunnel-id: 10<br />
primary-path-state: trying-to-establish<br />
primary-path: tun-second-link<br />
secondary-path-state: established<br />
secondary-path: dyn<br />
active-path: dyn<br />
active-lspid: 3<br />
active-label: 45<br />
explicit-route: S:192.168.33.5/32,S:192.168.33.2/32,S:192.168.33.1/32<br />
reserved-bandwidth: 5.0Mbps<br />
<br />
</pre><br />
<br />
By default tunnel will try to switch back to primary path every minute. This setting can be changed with '''primary-retry-interval''' parameter.<br />
<br />
{{Note | Switching from primary to secondary path may not be as fast as expected. It depends on OSPF dead timeouts, routing table updates and timeout settings in TE tunnel configuration.}}<br />
<br />
==Extended Tunnel for VoIP==<br />
<br />
Lets consider that in network that we made previously, path through R4 has lower latency which is good for VoIP traffic. Since VOIP server is on LAN2 we will create another TE tunnel from R1 to R3 explicitly for VoIP traffic.<br />
<br />
[[File:Simple-te-extended.png| 700px | center]]<br />
<br />
Assuming that previous configuration is up and running, we will start with path definition for VOIP tunnel.<br />
<br />
'''R1'''<br />
<pre><br />
/mpls traffic-eng tunnel-path<br />
add name=tun-second-link use-cspf=no \<br />
hops=192.168.33.13:strict,192.168.33.10:strict,192.168.33.9:strict<br />
<br />
/interface traffic-eng<br />
add name=TE-to-R3-VOIP to-address=10.255.0.3 bandwidth=5Mbps record-route=yes \<br />
primary-path=tun-second-link secondary-paths=dyn reoptimize-interval=5s<br />
</pre><br />
<br />
<br />
Verify that tunnel is up and running<br />
<pre><br />
<br />
[admin@R1] /interface traffic-eng> monitor TE-to-R3-VOIP<br />
tunnel-id: 19<br />
primary-path-state: established<br />
primary-path: tun-second-link<br />
secondary-path-state: not-necessary<br />
active-path: tun-second-link<br />
active-lspid: 1<br />
active-label: 20<br />
explicit-route: S:192.168.33.13/32,S:192.168.33.10/32,S:192.168.33.9/32<br />
recorded-route: 192.168.33.10[20],192.168.33.9[0]<br />
reserved-bandwidth: 5.0Mbps<br />
<br />
</pre><br />
<br />
Notice that we are doing configuration only in one direction, since traffic coming back form the server will use the same tunnel as regular data.<br />
<br />
Now it is time to set up routing.<br />
<br />
Let's consider that VoIP server's IP address is 192.168.20.250. We will also need to set up IP addresses on tunnel ends.<br />
<br />
'''R1'''<br />
<pre><br />
/ip address add address=10.100.100.1/30 interface=TE-to-R3-VOIP<br />
<br />
/ip route add dst-address=192.168.20.250/32 gateway=10.100.100.2<br />
</pre><br />
<br />
'''R3'''<br />
<pre><br />
/ip address add address=10.100.100.2/30 interface=TE-to-R1<br />
</pre><br />
<br />
==See More==<br />
<br />
* [[M:TE_tunnel_auto_bandwidth | TE Tunnel Auto Bandwidth]]<br />
* [[M:TE_Tunnels | TE Tunnels]]<br />
<br />
<br />
{{cont}}<br />
<br />
[[Category:Manual | T]]<br />
[[Category:Examples | T]]<br />
[[Category:MPLS | T]]<br />
[[Category:Internetworking | T]]<br />
[[Category:QoS| T]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Queues_-_PCQ&diff=21847Manual:Queues - PCQ2011-09-14T06:46:53Z<p>Megis: /* Usage */</p>
<hr />
<div>{{Versions|2.9, v3, v4}}<br />
<br />
__TOC__<br />
<br />
==Usage==<br />
<br />
PCQ was introduced to optimize massive QoS systems, where most of the queues are exactly the same for different sub-streams. For example a sub-stream can be download or upload for one particular client (IP) or connection to server.<br />
<br />
PCQ algorithm is very simple - at first it uses selected classifiers to distinguish one sub-stream from another, then applies individual FIFO queue size and limitation on every sub-stream, then groups all sub-streams together and applies global FIFO queue size and limitation.<br />
<br />
PCQ parameters:<br />
* '''pcq-classifier''' (dst-address | dst-port | src-address | src-port; default: "") : selection of sub-stream identifiers <br />
* '''pcq-rate''' (number) : maximal available data rate of each sub-steam <br />
* '''pcq-limit''' (number) : queue size of single sub-stream (in KB)<br />
* '''pcq-total-limit''' (number) : queue size of global FIFO queue (in KB)<br />
<br />
<br />
[[Image:PCQ_Alg.png|400px|PCQ Algorithm]]<br />
<br />
<br />
So instead of having 100 queues with 1000kbps limitation for download we can have one PCQ queue with 100 sub-streams<br />
<br />
==Classification Examples==<br />
<br />
To better understand classification we will take a list of 18 packet streams from specific address and port, to a specific address and port. Then we will choose a classifier and divide all 18 packet streams into PCQ sub-streams <br />
<br />
[[Image:PCQ_Example1.png|700px|Classifiers]]<br />
<br />
[[Image:PCQ_Example2.png|700px|Classifiers]]<br />
<br />
==PCQ Rate Examples==<br />
<br />
Here it is possible to see what happens if PCQ-rate is, or isn't specified. I must noted that if both limits (pcq-rate and max-limit) are unspecified, queue behavior can be imprecise. So it is strongly suggested to have at least one of these options set.<br />
<br />
<br />
[[Image:PCQ3.png|500px|Classifiers]]<br />
<br />
<br />
[[Image:PCQ4.png|500px|Classifiers]]<br />
<br />
==New PCQ implementation (v5.0RC5)==<br />
<br />
PCQ was rewritten in v5.0RC4 to optimize it high throughput both in Mbps and pps. This implementation properly utilize all new Linux Kernel features, this makes PCQ faster and less resource demanding. <br />
<br />
Now as soon as new stream activates it will get 1/4th of rate with highest priority. If rate is "0" sub-stream will not have this feature (as 1/4th of "0" is "0")<br />
<br />
This is necessary to know for one good reason:<br />
Lets assume that sub-stream's rate is 10Mbps, so in the moment when new sub-stream will request traffic it will get first 2500k of traffic without limitation. This may result in higher that expected results in such programs as Speedtest.net. To avoid that make sure that Speedtest.net is not the first program that utilize bandwidth that you run on PC.<br />
<br />
Also starting from v5.0RC5 PCQ have new features <br />
<br />
PCQ Burst for sub-streams. PCQ will have burst implementation identical to Simple Queues and Queue Tree<br />
<br />
PCQ parameters:<br />
* '''pcq-burst-rate''' (number) : maximal upload/download data rate which can be reached while the burst for substream is allowed <br />
* '''pcq-burst-threshold''' (number) : this is value of burst on/off switch<br />
* '''pcq-burst-time''' (time) : period of time, in seconds, over which the average data rate is calculated. (This is NOT the time of actual burst) <br />
<br />
For detailed burst explanation refer to:<br />
* [[Burst]]<br />
<br />
PCQ also allows to use different size IPv4 and IPv6 networks as sub-stream identifiers . Before it was locked to single IP address. This is done mainly for IPv6 as customers from ISP point of view will be represented by /64 network, but devices in customers network will be /128. PCQ can be used for both of these scenarios and more.<br />
<br />
PCQ parameters:<br />
* '''pcq-dst-address-mask''' (number) : size of IPv4 network that will be used as dst-address sub-stream identifier<br />
* '''pcq-src-address-mask''' (number) : size of IPv4 network that will be used as src-address sub-stream identifier<br />
* '''pcq-dst-address6-mask''' (number) : size of IPV6 network that will be used as dst-address sub-stream identifier<br />
* '''pcq-src-address6-mask''' (number) : size of IPV6 network that will be used as src-address sub-stream identifier<br />
<br />
<br />
== See Also ==<br />
<br />
* [[PCQ Examples]]<br />
<br />
[[Category:Manual|QueuesPCQ]]<br />
[[Category:QoS|QueuesPCQ]]<br />
[[Category:Case Studies|QueuesPCQ]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=21047Manual:Maximum Transmission Unit on RouterBoards2011-05-23T09:57:15Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows max-l2mtu supported by Mikrotik RouterBoards (Starting from the RouterOS v5.4 also available in "/interface print" menu as value of read-only "max-l2mtu" option):<br />
<br />
'''Integrated Solutions'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>Groove A-5Hn, Groove 5Hn, SXT 5HnD</b></td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >4076</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750GL</b></td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1200</b></td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9116</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
'''RouterBOARD'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411U, RB411AR, RB411AH, RB411UAHR</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH, RB433UAH, RB450, RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB435G, RB450G, RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB711-5Hn-M, RB711-5Hn-U, RB711A-5Hn-M</b></td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
<br />
'''Old Products'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A, RB1000</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<tr><br />
<td ><b>RB532, CrossRoads</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=21046Manual:Maximum Transmission Unit on RouterBoards2011-05-23T09:55:13Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
<br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows max-l2mtu supported by Mikrotik RouterBoards (Starting from the RouterOS v5.4 also available in /import menu as value of "max-l2mtu" option):<br />
<br />
'''Integrated Solutions'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>Groove A-5Hn, Groove 5Hn, SXT 5HnD</b></td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >4076</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750GL</b></td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1200</b></td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9116</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
'''RouterBOARD'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411U, RB411AR, RB411AH, RB411UAHR</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH, RB433UAH, RB450, RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB435G, RB450G, RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB711-5Hn-M, RB711-5Hn-U, RB711A-5Hn-M</b></td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
<br />
'''Old Products'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A, RB1000</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<tr><br />
<td ><b>RB532, CrossRoads</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=21044Manual:Maximum Transmission Unit on RouterBoards2011-05-23T09:51:05Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows max-l2mtu supported by Mikrotik RouterBoards:<br />
<br />
'''Integrated Solutions'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>Groove A-5Hn, Groove 5Hn, SXT 5HnD</b></td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >4076</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750GL</b></td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1200</b></td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9116</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
'''RouterBOARD'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411U, RB411AR, RB411AH, RB411UAHR</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH, RB433UAH, RB450, RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB435G, RB450G, RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB711-5Hn-M, RB711-5Hn-U, RB711A-5Hn-M</b></td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
<br />
'''Old Products'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A, RB1000</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<tr><br />
<td ><b>RB532, CrossRoads</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=21040Manual:Maximum Transmission Unit on RouterBoards2011-05-23T09:34:51Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows max-l2mtu supported by Mikrotik RouterBoards:<br />
<br />
'''Integrated Solutions'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>Groove A-5Hn, Groove 5Hn, SXT 5HnD</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB750, RB750GL</b></td><br />
<td >4076</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1200</b></td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9116</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
'''RouterBOARD'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411U, RB411AR, RB411AH, RB411UAHR</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH, RB433UAH, RB450, RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB435G, RB450G, RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB711-5Hn-M, RB711-5Hn-U, RB711A-5Hn-M</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
<br />
'''Old Products'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A, RB1000</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<tr><br />
<td ><b>RB532, CrossRoads</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=21039Manual:Maximum Transmission Unit on RouterBoards2011-05-23T09:33:24Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows max-l2mtu supported by Mikrotik RouterBoards:<br />
<br />
'''Integrated Solutions'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>Groove A-5Hn, Groove 5Hn, SXT 5HnD</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB750, RB750GL</b></td><br />
<td >4076</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1200</b></td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9116</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
'''RouterBOARD'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411U, RB411AR, RB411AH, RB411UAHR</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH, RB433UAH, RB450 , RB493 , RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB435G, RB450G, RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB711-5Hn-M, RB711-5Hn-U, RB711A-5Hn-M</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
<br />
'''Old Products'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A, RB1000</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<tr><br />
<td ><b>RB532, CrossRoads</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=21038Manual:Maximum Transmission Unit on RouterBoards2011-05-23T09:31:50Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows max-l2mtu supported by Mikrotik RouterBoards:<br />
<br />
'''Integrated Solutions'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>Groove A-5Hn, Groove 5Hn, SXT 5HnD</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB750, RB750GL</b></td><br />
<td >4076</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
<td >4074</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1200</b></td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >8998</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9116</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9498</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
'''RouterBOARD'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411U, RB411AR, RB411AH, RB411UAHR</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH, RB433UAH,RB450, RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB435G, RB450G, RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB711-5Hn-M, RB711-5Hn-U, RB711A-5Hn-M</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
</table><br />
<br />
'''Old Products'''<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A, RB1000</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<tr><br />
<td ><b>RB532, CrossRoads</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
<td >7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
<td >9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=20989Manual:Maximum Transmission Unit on RouterBoards2011-05-16T07:17:32Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates the maximum size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows L2MTU supported by Mikrotik RouterBoards:<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="40">ether1</th><br />
<th width="40">ether2</th><br />
<th width="40">ether3</th><br />
<th width="40">ether4</th><br />
<th width="40">ether5</th><br />
<th width="40">ether6</th><br />
<th width="40">ether7</th><br />
<th width="40">ether8</th><br />
<th width="40">ether9</th><br />
<th width="40">ether10</th><br />
<th width="40">ether11-13</th><br />
</tr><br />
<tr><br />
<td ><b>SXT 5HnD</b></td><br />
<td >4076</td><br />
</tr><br />
<tr><br />
<td ><b>RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB493G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td> <br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB435G</b></td><br />
<td >1524 </td><br />
<td >1524 </td><br />
<td >1524 </td><br />
</tr><br />
<tr><br />
<td ><b>RB450</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411A, RB411AH</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB450G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750 (AR7241)</b></td><br />
<td >4076</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
<td >2030</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1000</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9000</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9116</td><br />
</tr><br />
<tr><br />
<td ><b>CrossRoads</b></td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB532</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png | 740px]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png | 740px]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png | 740px]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png | 740px]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png|740px]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:PCC&diff=20688Manual:PCC2011-03-22T11:15:06Z<p>Megis: </p>
<hr />
<div>{{Versions|v3, v4}}<br />
<br />
== Introduction == <br />
<br />
PCC matcher will allow you to divide traffic into equal streams with ability to keep packets with specific set of options in one particular stream (you can specify this set of options from src-address, src-port, dst-address, dst-port) <br />
<br />
===Theory===<br />
PCC takes selected fields from IP header, and with the help of a hashing algorithm converts selected fields into 32-bit value. This value then is divided by a specified ''Denominator'' and the remainder then is compared to a specified ''Remainder'', if equal then packet will be captured. You can choose from src-address, dst-address, src-port, dst-port from the header to use in this operation. <br />
<br />
<pre><br />
per-connection-classifier=<br />
PerConnectionClassifier ::= [!]ValuesToHash:Denominator/Remainder<br />
Remainder ::= 0..4294967295 (integer number)<br />
Denominator ::= 1..4294967295 (integer number)<br />
ValuesToHash ::= both-addresses|both-ports|dst-address-and-port|<br />
src-address|src-port|both-addresses-and-ports|dst-address|dst-port|src-address-and-port <br />
</pre><br />
<br />
===Example===<br />
This configuration will divide all connections into 3 groups based on source address and port<br />
<br />
<pre><br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=1st_conn per-connection-classifier=src-address-and-port:3/0<br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=2nd_conn per-connection-classifier=src-address-and-port:3/1<br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=3rd_conn per-connection-classifier=src-address-and-port:3/2<br />
</pre><br />
<br />
===Notes===<br />
<br />
PCC is available in RouterOS since v3.24. This option was introduced to address configuration issues with load balancing over multiple gateways with masquerade<br />
<br />
Previous configurations:<br />
* [[ECMP load balancing with masquerade]]<br />
* [[NTH load balancing with masquerade]]<br />
* [[NTH load balancing with masquerade (another approach)]]<br />
<br />
<br />
==Application Example - Load Balancing==<br />
<br />
Consider the following network layout:<br />
<br />
[[Image:LoadBalancing.png]]<br />
<br />
====Quick Start for Impatient====<br />
Configuration export from the gateway router:<br />
<pre><br />
/ ip address<br />
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=LAN<br />
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=ISP1<br />
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=ISP2<br />
<br />
/ ip firewall mangle<br />
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=LAN<br />
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=LAN<br />
add chain=prerouting in-interface=ISP1 connection-mark=no-mark action=mark-connection \<br />
new-connection-mark=ISP1_conn<br />
add chain=prerouting in-interface=ISP2 connection-mark=no-mark action=mark-connection \ <br />
new-connection-mark=ISP2_conn<br />
add chain=prerouting in-interface=LAN connection-mark=no-mark dst-address-type=!local \<br />
per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=ISP1_conn <br />
add chain=prerouting in-interface=LAN connection-mark=no-mark dst-address-type=!local \ <br />
per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=ISP2_conn<br />
add chain=prerouting connection-mark=ISP1_conn in-interface=LAN action=mark-routing \ <br />
new-routing-mark=to_ISP1<br />
add chain=prerouting connection-mark=ISP2_conn in-interface=LAN action=mark-routing \<br />
new-routing-mark=to_ISP2<br />
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 <br />
add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2<br />
<br />
/ ip route<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_ISP1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_ISP2 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping<br />
<br />
/ ip firewall nat <br />
add chain=srcnat out-interface=ISP1 action=masquerade<br />
add chain=srcnat out-interface=ISP2 action=masquerade<br />
</pre><br />
<br />
===Explanation===<br />
<br />
Let's assume this configuration: <br />
<br />
====IP Addresses====<br />
<pre><br />
/ ip address <br />
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=LAN<br />
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=ISP1<br />
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=ISP2<br />
</pre><br />
<br />
The router has two upstream (ISP) interfaces with the addresses of 10.111.0.2/24 and 10.112.0.2/24.<br />
The LAN interface has IP address of 192.168.0.1/24.<br />
<br />
====Policy routing====<br />
<pre><br />
/ ip firewall mangle<br />
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=LAN<br />
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=LAN<br />
</pre><br />
With policy routing it is possible to force all traffic to the specific gateway, even if traffic is destined to the host (other that gateway) from the connected networks. This way routing loop will be generated and communications with those hosts will be impossible.<br />
To avoid this situation we need to allow usage of default routing table for traffic to connected networks.<br />
<br />
<pre><br />
add chain=prerouting in-interface=ISP1 connection-mark=no-mark action=mark-connection \<br />
new-connection-mark=ISP1_conn<br />
add chain=prerouting in-interface=ISP2 connection-mark=no-mark action=mark-connection \ <br />
new-connection-mark=ISP2_conn<br />
</pre><br />
First it is necessary to manage connection initiated from outside - replies must leave via same interface (from same Public IP) request came.<br />
We will mark all new incoming connections, to remember what was the interface.<br />
<br />
<pre> <br />
add chain=prerouting in-interface=LAN connection-mark=no-mark dst-address-type=!local \<br />
per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=ISP1_conn <br />
add chain=prerouting in-interface=LAN connection-mark=no-mark dst-address-type=!local \ <br />
per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=ISP2_conn<br />
</pre><br />
Action mark-routing can be used only in mangle chain '''output''' and '''prerouting''', but mangle chain '''prerouting''' is capturing all traffic that is going to the router itself.<br />
To avoid this we will use ''dst-address-type=!local''. And with the help of the new PCC we will divide traffic into two groups based on source and destination addressees.<br />
<br />
<pre><br />
add chain=prerouting connection-mark=ISP1_conn in-interface=LAN action=mark-routing \ <br />
new-routing-mark=to_ISP1<br />
add chain=prerouting connection-mark=ISP2_conn in-interface=LAN action=mark-routing \<br />
new-routing-mark=to_ISP2<br />
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 <br />
add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2<br />
</pre><br />
<br />
Then we need to mark all packets from those connections with a proper mark. As policy routing is required only for traffic going to the Internet, do not forget to specify in-interface option.<br />
<br />
<pre><br />
/ ip route<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_ISP1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_ISP2 check-gateway=ping<br />
</pre><br />
<br />
Create a route for each routing-mark<br />
<br />
<pre><br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping<br />
</pre><br />
To enable failover, it is necessary to have routes that will jump in as soon as others will become inactive on gateway failure. (and that will happen only if check-gateway option is active)<br />
<br />
====NAT====<br />
<br />
<pre><br />
/ ip firewall nat <br />
add chain=srcnat out-interface=ISP1 action=masquerade<br />
add chain=srcnat out-interface=ISP2 action=masquerade<br />
</pre><br />
<br />
As routing decision is already made we just need rules that will fix src-addresses for all outgoing packets. If this packet will leave via wlan1 it will be NATed to 10.112.0.2,<br />
if via wlan2 then NATed to 10.111.0.2 <br />
<br />
<br />
[[Category: Manual|PCC]]<br />
[[Category: IP|PCC]]<br />
[[Category: Firewall|PCC]]<br />
[[Category: Examples|PCC]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:PCC&diff=20687Manual:PCC2011-03-22T11:01:36Z<p>Megis: /* Quick Start for Impatient */</p>
<hr />
<div>{{Versions|v3, v4}}<br />
<br />
== Introduction == <br />
<br />
PCC matcher will allow you to divide traffic into equal streams with ability to keep packets with specific set of options in one particular stream (you can specify this set of options from src-address, src-port, dst-address, dst-port) <br />
<br />
===Theory===<br />
PCC takes selected fields from IP header, and with the help of a hashing algorithm converts selected fields into 32-bit value. This value then is divided by a specified ''Denominator'' and the remainder then is compared to a specified ''Remainder'', if equal then packet will be captured. You can choose from src-address, dst-address, src-port, dst-port from the header to use in this operation. <br />
<br />
<pre><br />
per-connection-classifier=<br />
PerConnectionClassifier ::= [!]ValuesToHash:Denominator/Remainder<br />
Remainder ::= 0..4294967295 (integer number)<br />
Denominator ::= 1..4294967295 (integer number)<br />
ValuesToHash ::= both-addresses|both-ports|dst-address-and-port|<br />
src-address|src-port|both-addresses-and-ports|dst-address|dst-port|src-address-and-port <br />
</pre><br />
<br />
===Example===<br />
This configuration will divide all connections into 3 groups based on source address and port<br />
<br />
<pre><br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=1st_conn per-connection-classifier=src-address-and-port:3/0<br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=2nd_conn per-connection-classifier=src-address-and-port:3/1<br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=3rd_conn per-connection-classifier=src-address-and-port:3/2<br />
</pre><br />
<br />
===Notes===<br />
<br />
PCC is available in RouterOS since v3.24. This option was introduced to address configuration issues with load balancing over multiple gateways with masquerade<br />
<br />
Previous configurations:<br />
* [[ECMP load balancing with masquerade]]<br />
* [[NTH load balancing with masquerade]]<br />
* [[NTH load balancing with masquerade (another approach)]]<br />
<br />
<br />
==Application Example - Load Balancing==<br />
<br />
Consider the following network layout:<br />
<br />
[[Image:LoadBalancing.png]]<br />
<br />
====Quick Start for Impatient====<br />
Configuration export from the gateway router:<br />
<pre><br />
/ ip address<br />
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=LAN<br />
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=ISP1<br />
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=ISP2<br />
<br />
/ ip firewall mangle<br />
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=LAN<br />
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=LAN<br />
add chain=prerouting in-interface=ISP1 connection-mark=no-mark action=mark-connection \<br />
new-connection-mark=ISP1_conn<br />
add chain=prerouting in-interface=ISP2 connection-mark=no-mark action=mark-connection \ <br />
new-connection-mark=ISP2_conn<br />
add chain=prerouting in-interface=LAN connection-mark=no-mark dst-address-type=!local \<br />
per-connection-classifier=both-addresses:2/0 action=mark-connection new-connection-mark=ISP1_conn <br />
add chain=prerouting in-interface=LAN connection-mark=no-mark dst-address-type=!local \ <br />
per-connection-classifier=both-addresses:2/1 action=mark-connection new-connection-mark=ISP2_conn<br />
add chain=prerouting connection-mark=ISP1_conn in-interface=LAN action=mark-routing \ <br />
new-routing-mark=to_ISP1<br />
add chain=prerouting connection-mark=ISP2_conn in-interface=LAN action=mark-routing \<br />
new-routing-mark=to_ISP2<br />
add chain=output connection-mark=ISP1_conn action=mark-routing new-routing-mark=to_ISP1 <br />
add chain=output connection-mark=ISP2_conn action=mark-routing new-routing-mark=to_ISP2<br />
<br />
/ ip route<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_ISP1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_ISP2 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping<br />
<br />
/ ip firewall nat <br />
add chain=srcnat out-interface=ISP1 action=masquerade<br />
add chain=srcnat out-interface=ISP2 action=masquerade<br />
</pre><br />
<br />
===Explanation===<br />
<br />
Let's assume this configuration: <br />
<br />
====IP Addresses====<br />
<pre><br />
/ ip address <br />
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=Local<br />
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=wlan1 <br />
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=wlan2 <br />
</pre><br />
<br />
The router has two upstream (WAN) interfaces with the addresses of 10.111.0.2/24 and 10.112.0.2/24.<br />
The LAN interface has the name "Local" and IP address of 192.168.0.1/24.<br />
<br />
====Policy routing====<br />
<br />
<br />
<pre><br />
/ ip firewall mangle<br />
add chain=input in-interface=wlan1 action=mark-connection new-connection-mark=wlan1_conn<br />
add chain=input in-interface=wlan2 action=mark-connection new-connection-mark=wlan2_conn<br />
</pre><br />
First it is necessary to take care of router's traffic - we need to make sure that traffic will leave via same interface it was coming from.<br />
We will mark all incoming connections, to remember what was the interface.<br />
<pre><br />
add chain=output connection-mark=wlan1_conn action=mark-routing new-routing-mark=to_wlan1 <br />
add chain=output connection-mark=wlan2_conn action=mark-routing new-routing-mark=to_wlan2<br />
</pre><br />
Then we will assign proper routing-mark to the packets leaving the router. <br />
<pre><br />
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=Local <br />
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=Local<br />
</pre><br />
With policy routing it is possible to force all traffic to the specific gateway, even if traffic is destined to the host (other that gateway) in the connected networks. This way routing loop will be generated and communications with those hosts will be impossible.<br />
To avoid this situation we need to allow usage of default routing table for traffic to connected networks.<br />
<pre> <br />
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/0 \<br />
action=mark-connection new-connection-mark=wlan1_conn passthrough=yes<br />
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/1 \<br />
action=mark-connection new-connection-mark=wlan2_conn passthrough=yes<br />
</pre><br />
Action mark-routing can be used only in mangle chain '''output''' and '''prerouting''', but mangle chain '''prerouting''' is capturing all traffic that is going to the router itself.<br />
To avoid this we will use ''dst-address-type=!local''. And with the help of the new PCC we will divide traffic into two groups based on source and destination addressees.<br />
<br />
<pre><br />
add chain=prerouting connection-mark=wlan1_conn in-interface=Local action=mark-routing new-routing-mark=to_wlan1<br />
add chain=prerouting connection-mark=wlan2_conn in-interface=Local action=mark-routing new-routing-mark=to_wlan2<br />
</pre><br />
<br />
Then we need to mark all packets from those connections with a proper mark. As policy routing is required only for traffic going to the Internet, do not forget to specify in-interface option.<br />
<br />
<pre><br />
/ ip route<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_wlan1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_wlan2 check-gateway=ping<br />
</pre><br />
<br />
Create a route for each routing-mark<br />
<br />
<pre><br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping<br />
</pre><br />
To enable failover, it is necessary to have routes that will jump in as soon as others will become inactive on gateway failure. (and that will happen only if check-gateway option is active)<br />
<br />
====NAT====<br />
<br />
<pre><br />
/ ip firewall nat <br />
add chain=srcnat out-interface=wlan1 action=masquerade<br />
add chain=srcnat out-interface=wlan2 action=masquerade<br />
</pre><br />
<br />
As routing decision is already made we just need rules that will fix src-addresses for all outgoing packets. If this packet will leave via wlan1 it will be NATed to 10.112.0.2,<br />
if via wlan2 then NATed to 10.111.0.2 <br />
<br />
<br />
[[Category: Manual|PCC]]<br />
[[Category: IP|PCC]]<br />
[[Category: Firewall|PCC]]<br />
[[Category: Examples|PCC]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Queues_-_PCQ&diff=19822Manual:Queues - PCQ2010-12-02T13:38:41Z<p>Megis: </p>
<hr />
<div>{{Versions|2.9, v3, v4}}<br />
<br />
__TOC__<br />
<br />
==Usage==<br />
<br />
PCQ was introduced to optimize massive QoS systems, where most of the queues are exactly the same for different sub-streams. For example a sub-stream can be download or upload for one particular client (IP) or connection to server.<br />
<br />
PCQ algorithm is very simple - at first it uses selected classifiers to distinguish one sub-stream from another, then applies individual FIFO queue size and limitation on every sub-stream, then groups all sub-streams together and applies global FIFO queue size and limitation.<br />
<br />
PCQ parameters:<br />
* '''pcq-classifier''' (dst-address | dst-port | src-address | src-port; default: "") : selection of sub-stream identifiers <br />
* '''pcq-rate''' (number) : maximal available data rate of each sub-steam <br />
* '''pcq-limit''' (number) : queue size of one sub-stream in packets<br />
* '''pcq-total-limit''' (number) : queue size of global FIFO queue<br />
<br />
<br />
[[Image:PCQ_Alg.png|400px|PCQ Algorithm]]<br />
<br />
<br />
So instead of having 100 queues with 1000kbps limitation for download we can have one PCQ queue with 100 sub-streams<br />
<br />
==Classification Examples==<br />
<br />
To better understand classification we will take a list of 18 packet streams from specific address and port, to a specific address and port. Then we will choose a classifier and divide all 18 packet streams into PCQ sub-streams <br />
<br />
[[Image:PCQ_Example1.png|700px|Classifiers]]<br />
<br />
[[Image:PCQ_Example2.png|700px|Classifiers]]<br />
<br />
==PCQ Rate Examples==<br />
<br />
Here it is possible to see what happens if PCQ-rate is, or isn't specified. I must noted that if both limits (pcq-rate and max-limit) are unspecified, queue behavior can be imprecise. So it is strongly suggested to have at least one of these options set.<br />
<br />
<br />
[[Image:PCQ3.png|500px|Classifiers]]<br />
<br />
<br />
[[Image:PCQ4.png|500px|Classifiers]]<br />
<br />
==New PCQ implementation (v5.0RC5)==<br />
<br />
PCQ was rewritten in v5.0RC4 to optimize it high throughput both in Mbps and pps. This implementation properly utilize all new Linux Kernel features, this makes PCQ faster and less resource demanding. <br />
<br />
Now as soon as new stream activates it will get 1/4th of rate with highest priority. If rate is "0" sub-stream will not have this feature (as 1/4th of "0" is "0")<br />
<br />
This is necessary to know for one good reason:<br />
Lets assume that sub-stream's rate is 10Mbps, so in the moment when new sub-stream will request traffic it will get first 2500k of traffic without limitation. This may result in higher that expected results in such programs as Speedtest.net. To avoid that make sure that Speedtest.net is not the first program that utilize bandwidth that you run on PC.<br />
<br />
Also starting from v5.0RC5 PCQ have new features <br />
<br />
PCQ Burst for sub-streams. PCQ will have burst implementation identical to Simple Queues and Queue Tree<br />
<br />
PCQ parameters:<br />
* '''pcq-burst-rate''' (number) : maximal upload/download data rate which can be reached while the burst for substream is allowed <br />
* '''pcq-burst-threshold''' (number) : this is value of burst on/off switch<br />
* '''pcq-burst-time''' (time) : period of time, in seconds, over which the average data rate is calculated. (This is NOT the time of actual burst) <br />
<br />
For detailed burst explanation refer to:<br />
* [[Burst]]<br />
<br />
PCQ also allows to use different size IPv4 and IPv6 networks as sub-stream identifiers . Before it was locked to single IP address. This is done mainly for IPv6 as customers from ISP point of view will be represented by /64 network, but devices in customers network will be /128. PCQ can be used for both of these scenarios and more.<br />
<br />
PCQ parameters:<br />
* '''pcq-dst-address-mask''' (number) : size of IPv4 network that will be used as dst-address sub-stream identifier<br />
* '''pcq-src-address-mask''' (number) : size of IPv4 network that will be used as src-address sub-stream identifier<br />
* '''pcq-dst-address6-mask''' (number) : size of IPV6 network that will be used as dst-address sub-stream identifier<br />
* '''pcq-src-address6-mask''' (number) : size of IPV6 network that will be used as src-address sub-stream identifier<br />
<br />
<br />
== See Also ==<br />
<br />
* [[PCQ Examples]]<br />
<br />
[[Category:Manual|QueuesPCQ]]<br />
[[Category:QoS|QueuesPCQ]]<br />
[[Category:Case Studies|QueuesPCQ]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:PCC&diff=17561Manual:PCC2010-05-19T11:59:51Z<p>Megis: /* IP Addresses */</p>
<hr />
<div>{{Versions|3, v4}}<br />
<br />
== Introduction == <br />
<br />
PCC matcher will allow you to divide traffic into equal streams with ability to keep packets with specific set of options in one particular stream (you can specify this set of options from src-address, src-port, dst-address, dst-port) <br />
<br />
===Theory===<br />
PCC takes selected fields from IP header, and with the help of a hashing algorithm converts selected fields into 32-bit value. This value then is divided by a specified ''Denominator'' and the remainder then is compared to a specified ''Remainder'', if equal then packet will be captured. You can choose from src-address, dst-address, src-port, dst-port from the header to use in this operation. <br />
<br />
<pre><br />
per-connection-classifier=<br />
PerConnectionClassifier ::= [!]ValuesToHash:Denominator/Remainder<br />
Remainder ::= 0..4294967295 (integer number)<br />
Denominator ::= 1..4294967295 (integer number)<br />
ValuesToHash ::= both-addresses|both-ports|dst-address-and-port|<br />
src-address|src-port|both-addresses-and-ports|dst-address|dst-port|src-address-and-port <br />
</pre><br />
<br />
===Example===<br />
This configuration will divide all connections into 3 groups based on source address and port<br />
<br />
<pre><br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=1st_conn per-connection-classifier=src-address-and-port:3/0<br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=2nd_conn per-connection-classifier=src-address-and-port:3/1<br />
/ip firewall mangle add chain=prerouting action=mark-connection \<br />
new-connection-mark=3rd_conn per-connection-classifier=src-address-and-port:3/2<br />
</pre><br />
<br />
===Notes===<br />
<br />
PCC is available in RouterOS since v3.24. This option was introduced to address configuration issues with load balancing over multiple gateways with masquerade<br />
<br />
Previous configurations:<br />
* [[ECMP load balancing with masquerade]]<br />
* [[NTH load balancing with masquerade]]<br />
* [[NTH load balancing with masquerade (another approach)]]<br />
<br />
<br />
==Application Example - Load Balancing==<br />
<br />
Consider the following network layout:<br />
<br />
[[Image:LoadBalancing.png]]<br />
<br />
====Quick Start for Impatient====<br />
Configuration export from the gateway router:<br />
<pre><br />
/ ip address<br />
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=Local <br />
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=wlan1<br />
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=wlan2<br />
<br />
/ ip firewall mangle<br />
add chain=input in-interface=wlan1 action=mark-connection new-connection-mark=wlan1_conn<br />
add chain=input in-interface=wlan2 action=mark-connection new-connection-mark=wlan2_conn<br />
add chain=output connection-mark=wlan1_conn action=mark-routing new-routing-mark=to_wlan1 <br />
add chain=output connection-mark=wlan2_conn action=mark-routing new-routing-mark=to_wlan2<br />
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=Local <br />
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=Local<br />
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/0 \<br />
action=mark-connection new-connection-mark=wlan1_conn passthrough=yes<br />
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/1 \<br />
action=mark-connection new-connection-mark=wlan2_conn passthrough=yes<br />
add chain=prerouting connection-mark=wlan1_conn in-interface=Local action=mark-routing new-routing-mark=to_wlan1<br />
add chain=prerouting connection-mark=wlan2_conn in-interface=Local action=mark-routing new-routing-mark=to_wlan2<br />
<br />
/ ip route<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_wlan1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_wlan2 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping<br />
<br />
/ ip firewall nat <br />
add chain=srcnat out-interface=wlan1 action=masquerade<br />
add chain=srcnat out-interface=wlan2 action=masquerade<br />
</pre><br />
<br />
===Explanation===<br />
<br />
Let's assume this configuration: <br />
<br />
====IP Addresses====<br />
<pre><br />
/ ip address <br />
add address=192.168.0.1/24 network=192.168.0.0 broadcast=192.168.0.255 interface=Local<br />
add address=10.111.0.2/24 network=10.111.0.0 broadcast=10.111.0.255 interface=wlan1 <br />
add address=10.112.0.2/24 network=10.112.0.0 broadcast=10.112.0.255 interface=wlan2 <br />
</pre><br />
<br />
The router has two upstream (WAN) interfaces with the addresses of 10.111.0.2/24 and 10.112.0.2/24.<br />
The LAN interface has the name "Local" and IP address of 192.168.0.1/24.<br />
<br />
====Policy routing====<br />
<br />
<br />
<pre><br />
/ ip firewall mangle<br />
add chain=input in-interface=wlan1 action=mark-connection new-connection-mark=wlan1_conn<br />
add chain=input in-interface=wlan2 action=mark-connection new-connection-mark=wlan2_conn<br />
</pre><br />
First it is necessary to take care of router's traffic - we need to make sure that traffic will leave via same interface it was coming from.<br />
We will mark all incoming connections, to remember what was the interface.<br />
<pre><br />
add chain=output connection-mark=wlan1_conn action=mark-routing new-routing-mark=to_wlan1 <br />
add chain=output connection-mark=wlan2_conn action=mark-routing new-routing-mark=to_wlan2<br />
</pre><br />
Then we will assign proper routing-mark to the packets leaving the router. <br />
<pre><br />
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=Local <br />
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=Local<br />
</pre><br />
With policy routing it is possible to force all traffic to the specific gateway, even if traffic is destined to the host (other that gateway) in the connected networks. This way routing loop will be generated and communications with those hosts will be impossible.<br />
To avoid this situation we need to allow usage of default routing table for traffic to connected networks.<br />
<pre> <br />
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/0 \<br />
action=mark-connection new-connection-mark=wlan1_conn passthrough=yes<br />
add chain=prerouting dst-address-type=!local in-interface=Local per-connection-classifier=both-addresses:2/1 \<br />
action=mark-connection new-connection-mark=wlan2_conn passthrough=yes<br />
</pre><br />
Action mark-routing can be used only in mangle chain '''output''' and '''prerouting''', but mangle chain '''prerouting''' is capturing all traffic that is going to the router itself.<br />
To avoid this we will use ''dst-address-type=!local''. And with the help of the new PCC we will divide traffic into two groups based on source and destination addressees.<br />
<br />
<pre><br />
add chain=prerouting connection-mark=wlan1_conn in-interface=Local action=mark-routing new-routing-mark=to_wlan1<br />
add chain=prerouting connection-mark=wlan2_conn in-interface=Local action=mark-routing new-routing-mark=to_wlan2<br />
</pre><br />
<br />
Then we need to mark all packets from those connections with a proper mark. As policy routing is required only for traffic going to the Internet, do not forget to specify in-interface option.<br />
<br />
<pre><br />
/ ip route<br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 routing-mark=to_wlan1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 routing-mark=to_wlan2 check-gateway=ping<br />
</pre><br />
<br />
Create a route for each routing-mark<br />
<br />
<pre><br />
add dst-address=0.0.0.0/0 gateway=10.111.0.1 distance=1 check-gateway=ping<br />
add dst-address=0.0.0.0/0 gateway=10.112.0.1 distance=2 check-gateway=ping<br />
</pre><br />
To enable failover, it is necessary to have routes that will jump in as soon as others will become inactive on gateway failure. (and that will happen only if check-gateway option is active)<br />
<br />
====NAT====<br />
<br />
<pre><br />
/ ip firewall nat <br />
add chain=srcnat out-interface=wlan1 action=masquerade<br />
add chain=srcnat out-interface=wlan2 action=masquerade<br />
</pre><br />
<br />
As routing decision is already made we just need rules that will fix src-addresses for all outgoing packets. If this packet will leave via wlan1 it will be NATed to 10.112.0.2,<br />
if via wlan2 then NATed to 10.111.0.2 <br />
<br />
<br />
[[Category: Manual|PCC]]<br />
[[Category: IP|PCC]]<br />
[[Category: Firewall|PCC]]<br />
[[Category: Examples|PCC]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=17506Manual:Maximum Transmission Unit on RouterBoards2010-05-17T05:49:40Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates maximal size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows L2MTU supported by Mikrotik RouterBoards:<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="50">ether1</th><br />
<th width="50">ether2</th><br />
<th width="50">ether3</th><br />
<th width="50">ether4</th><br />
<th width="50">ether5</th><br />
<th width="50">ether6</th><br />
<th width="50">ether7</th><br />
<th width="50">ether8</th><br />
<th width="50">ether9</th><br />
<th width="50">ether10</th><br />
<th width="50">ether11</th><br />
</tr><br />
<tr><br />
<td ><b>RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB450</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411A, RB411AH</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB450G</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1000</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9000</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9116</td><br />
<td >1500-9116</td><br />
<td >1500-9116</td><br />
</tr><br />
<tr><br />
<td ><b>CrossRoads</b></td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB532</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=17505Manual:Maximum Transmission Unit on RouterBoards2010-05-17T05:49:02Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates maximal size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows L2MTU supported by Mikrotik RouterBoards:<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="50">ether1</th><br />
<th width="50">ether2</th><br />
<th width="50">ether3</th><br />
<th width="50">ether4</th><br />
<th width="50">ether5</th><br />
<th width="50">ether6</th><br />
<th width="50">ether7</th><br />
<th width="50">ether8</th><br />
<th width="50">ether9</th><br />
<th width="50">ether10</th><br />
<th width="50">ether11</th><br />
</tr><br />
<tr><br />
<td ><b>RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB450</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411A, RB411AH</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB450G</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1000</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9000</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9116</td><br />
<td >1500-9116</td><br />
<td >1500-9116</td><br />
</tr><br />
<tr><br />
<td ><b>CrossRoads</b></td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB532</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megishttps://wiki.mikrotik.com/index.php?title=Manual:Maximum_Transmission_Unit_on_RouterBoards&diff=17504Manual:Maximum Transmission Unit on RouterBoards2010-05-17T05:48:13Z<p>Megis: /* MAC/Layer-2/L2 MTU */</p>
<hr />
<div>__TOC__<br />
<br />
=Background=<br />
<br />
It is sole responsibility of administrator to configure MTUs such that intended services and applications can be successfully implemented in network. In other words - administrator must make sure that MTUs are configured in a way that packet sizes does not exceed the capabilities of network equipment.<br />
<br />
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.<br />
<br />
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.<br />
<br />
This way some non-standard frames started to emerge:<br />
<br />
*'''Giant''' or '''Jumbo''' frames - frames that are bigger than standard (IEEE) Ethernet MTU<br />
*'''Baby Giant''' or '''Baby Jumbo''' frames - frames that are just slightly bigger that standard (IEEE) Ethernet MTU<br />
<br />
It is common now for Ethernet interfaces to support physical MTU above standard, but this can not be taken for granted. Abilities of other network equipment must be taken into account as well - for example, if 2 routers with Ethernet interfaces supporting physical MTU 1526 are connected through Ethernet switch, in order to successfully implement some application that will produce this big Ethernet frames, switch must also support forwarding such frames.<br />
<br />
=MTU on RouterOS=<br />
<br />
[[Image:MTU general explanation.png|left|300px|Different types of MTU]]<br />
<br />
<br />
Mikrotik RouterOS recognizes several types of MTU: <br />
<br />
*IP/Layer-3/L3 MTU<br />
<br />
*MPLS/Layer-2.5/L2.5 MTU<br />
<br />
*MAC/Layer-2/L2 MTU<br />
<br />
*Full frame MTU<br />
<br />
<br />
<br />
<br />
==Full frame MTU==<br />
<br />
Full frame MTU indicates the actual size of the frame that are sent by particular interface. Frame Checksum is not included as it is removed by Ethernet driver as soon as frame reach its destination. <br />
<br />
==MAC/Layer-2/L2 MTU ==<br />
<br />
L2MTU indicates maximal size of the frame without MAC header that can be sent by this interface. <br />
<br />
Starting from the RouterOS v3.25 L2MTU values can be seen in "/interface" menu. L2MTU support is added for all Routerboard related Ethernet interfaces, VLANs, Bridge, VPLS and wireless interfaces. Some of them support configuration of L2MTU value. All other Ethernet interfaces might indicate L2MTU only if the chip set is the same as Routerboard Ethernets. <br />
<br />
This will allow users to check if desired setup is possible. Users will be able to utilize additional bytes for VLAN and MPLS tags, or simple increase of interface MTU to get rid of the some unnecessary fragmentation.<br />
<br />
This table shows L2MTU supported by Mikrotik RouterBoards:<br />
<table class="styled_table"><br />
<tr><br />
<th width="100">RouterBoard</th><br />
<th width="50">ether1</th><br />
<th width="50">ether2</th><br />
<th width="50">ether3</th><br />
<th width="50">ether4</th><br />
<th width="50">ether5</th><br />
<th width="50">ether6</th><br />
<th width="50">ether7</th><br />
<th width="50">ether8</th><br />
<th width="50">ether9</th><br />
<th width="50">ether10</th><br />
<th width="50">ether11</th><br />
</tr><br />
<tr><br />
<td ><b>RB493, RB493AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td> <br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB450</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB433, RB433AH</b></td><br />
<td >1526</td><br />
<td >1522</td><br />
<td >1522</td><br />
</tr><br />
<tr><br />
<td ><b>RB411, RB411A, RB411AH</b></td><br />
<td >1526</td><br />
</tr><br />
<tr><br />
<td ><b>RB450G</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750</b></td><br />
<td >1526</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB750G</b></td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
<td >1524</td><br />
</tr><br />
<tr><br />
<td ><b>RB1000</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
</tr><br />
<tr><br />
<td ><b>RB1100</b></td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9498</td><br />
<td >1500-9116</td><br />
<td >1500-9116</td><br />
<td >1500-9116</td><br />
</tr><br />
<tr><br />
<td ><b>RB600, RB600A</b></td><br />
<td >1500-9500</td><br />
<td >1500-9500</td><br />
<td >1500-9000</td><br />
</tr><br />
<tr><br />
<td ><b>RB800</b></td><br />
<td >9500</td><br />
<td >9500</td><br />
<td >9116</td><br />
</tr><br />
<tr><br />
<td ><b>CrossRoads</b></td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB333</b></td><br />
<td >1632</td><br />
<td >1632</td><br />
<td >1632</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB1xx</b></td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1518</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
<td >1514</td><br />
</tr><br />
<br />
<tr><br />
<td ><b>RB532</b></td><br />
<td >1600</td><br />
<td >1600</td><br />
<td >1600</td><br />
</tr><br />
<tr><br />
<td ><b>RB44G</b></td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
<td >1500-7200</td><br />
</tr><br />
<tr><br />
<td ><b>RB44GV</b></td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
<td >1500-9000</td><br />
</tr><br />
</table><br />
<br />
<br />
All wireless interfaces in RouterOS (including Nstreme2)supports 2290 byte L2MTU<br />
<br />
==MPLS/Layer-2.5/L2.5 MTU==<br />
<br />
Configured in "/mpls interface" menu, specifies maximal size of packet, including MPLS labels, that is allowed to send out by the particular interface (default is 1508).<br />
<br />
Make sure that MPLS MTU is smaller or equal to L2MTU<br />
<br />
MPLS MTU affects packets depending on what action MPLS router is performing. It is strongly recommended that MPLS MTU is configured to the same value on all routers forming MPLS cloud because of effects MPLS MTU has on MPLS switched packets. This requirement means that all interfaces participating in MPLS cloud must be configured to the smallest MPLS MTU values among participating interfaces, therefore care must be taken to properly select hardware to be used.<br />
<br />
===MPLS Switching===<br />
<br />
If packet with labels included is bigger than MPLS MTU, MPLS tries to guess protocol that is carried inside MPLS frame.<br />
<br />
If this is IP packet, MPLS produces ICMP Need Fragment error. This behavior mimics IP protocol behavior. Note that this ICMP error is not routed back to originator of packet but is switched towards end of LSP, so that egress router can route it back.<br />
<br />
If this is not IP packet, MPLS simply drops it, because it does not know how to interpret the contents of packet. This feature is very important in situations where MPLS applications such as VPLS are used (where frames that are MPLS tagged are not IP packets, but e.g. encapsulated Ethernet frames as in case of VPLS) - if somewhere along the LSP MPLS MTU will be less than packet size prepared by ingress router, frames will simply get dropped.<br />
<br />
===IP ingress===<br />
<br />
When router first introduces label (or labels) on IP packet, and resulting packet size including MPLS labels exceeds MPLS MTU, router behaves as if interface MTU was exceeded - either fragments packet in fragments that does not exceed MPLS MTU when labels are attached (if IP Dont Fragment is not set), or generates ICMP Need Fragmentation error that is sent back to originator.<br />
<br />
===VPLS ingress===<br />
<br />
When router encapsulates Ethernet frame for forwarding over VPLS pseudowire, it checks if packet size with VPLS Control Word (4 bytes) and any necessary labels (usually 2 labels - 8 bytes), exceeds MPLS MTU of outgoing interface. If it does, VPLS fragments packet so that it honours MPLS MTU of outgoing interface. Packet is defragmented at egress point of VPLS pseudowire.<br />
<br />
==IP/Layer-3/L3 MTU==<br />
<br />
Configured as interface MTU setting (/interface <type> <name> set mtu=X). Specifies how big IP packets router is allowed to send out the particular interface.<br />
<br />
If router receives IP packet of size 1500, but MTU for outgoing interface is set to 1400, router will either fragment the packet (if "Don't Fragment" bit is not set in IP header) or drop the packet and send ICMP "Need Fragmentation" error back to originator (this is essential for Path MTU Discovery to work).<br />
<br />
Sometimes it can be bad idea to change IP MTU from its default 1500 bytes on router interfaces if complete path end-to-end is not in administrators control. Although IP fragmentation and end-to-end Path MTU Discovery is intended to handle this situation, if ICMP Need Fragmentation errors are filtered somewhere along the path, Path MTU Discovery will not work.<br />
<br />
There are several features in MikroTik RouterOS that can benefit from possibility to exceed standard MTU<br />
<br />
=Simple Examples=<br />
<br />
In these examples we will take a look at frames entering and leaving router via Ethernet interfaces.<br />
<br />
=== Simple Routing ===<br />
<br />
The image shows the packet MTU size for simple routing, packets size is not modified.<br />
<br />
<br />
[[Image:MTUSimpleRouting.png]]<br />
<br />
<br />
=== Routing with VLAN Encap ===<br />
<br />
Each VLAN tag is 4 bytes long, VLAN tag is added by router. L2-MTU is increased by 4 bytes.<br />
<br />
<br />
[[Image:MTUVLANENCAP.png]]<br />
<br />
<br />
=== Simple MPLS with tags===<br />
<br />
When MPLS is used as plain replacement for IP routing, only one label is attached to every packet, therefore packet size increases by 4 bytes, we have the situation with two MPLS labels. In order to be able to forward standard size (1500 bytes) IP packet without fragmentation, MPLS MTU must be set to at least 1508 for two MPLS labels.<br />
<br />
<br />
[[Image:MTUMPLS2Tags.png]]<br />
<br />
<br />
=== VPLS Tunnel ===<br />
<br />
Two MPLS labels are present, when remote endpoint is not directly attached. One MPLS label is used to get to remote endpoint, second label is used to identify VPLS tunnel.<br />
<br />
<br />
[[Image:MTUVPLS.png]]<br />
<br />
<br />
=L2MTU advanced example=<br />
<br />
In this example we will take a closer look at required L2MTU of all Ethernet like interfaces including Bridge, VLAN, VPLS interfaces.<br />
<br />
In this setup we will have 3 routers:<br />
* Q-in-Q router - this router will receive standard 1500 byte Ethernet frame and will add two VLAN tags to the packet. Then packet will be sent out via Ethernet network to the second router<br />
<br />
*VPLS router - this router will remove outer VLAN tag and will bridge packet with the remaining VLAN tag with VPLS tunnel. VPLS tunnel will take packet through the MPLS network to the third router.<br />
<br />
*MPLS Edge router - will remove VPLS and VLAN tags and bridge packet to the client Ethernet network.<br />
<br />
<br />
[[Image:L2MTU example.png]]<br />
<br />
<br />
<br />
{{Cont}}<br />
<br />
[[Category:Manual]]<br />
[[Category:Interface]]<br />
[[Category:Case Studies]]<br />
[[Category:Routerboard]]</div>Megis