An open letter to Mikrotik about bug fixes

This isn’t your typical “rag on Mikrotik” post.  I see some frustrations with the Mikrotik process, mainly in regards to getting ongoing bugs and issues fixed. Having a persistent bug continue for large amounts of times tends to make for a frustrating experience.  Mikrotik has made leaps and bounds in their Changelogs over the past couple of years, which has been a huge help in the decisions of what software versions to upgrade (or even downgrade) to.  But I think things get lost in the process. This results in ongoing bugs, which tend to get unburied if someone makes enough noise.

One of the biggest things I would like to see is a public bug tracking system like Redhat’s Bugzilla tracking system.  This would benefit the community as a whole and help users see some of the outstanding issues when they go to implement things.  Forums are a great tool, but due to the nature of them, you get a fair amount of mis-information and unrelated chatter.  Just because Joe says he is seeing a bug, doesn’t mean he has a confirmed bug.  Having a confirmed bug system that has information and able to have moderated comments would be beneficial in many ways:
1.Users with long term bugs they are experiencing or waiting on would be able to keep informed on open status of bugs.
2.Would cut down on the “non-scientific” nature of forums. Information could be specifically submitted in support of a confirmed bug. Bug reports normally include the conditions that need to be met or existing for the bug to manifest itself. Users can then confirm, under those specific conditions, if they are experiencing a certain bug.
3.Bugs that are important to users will get reported more often. This should lead to the more important bugs being upvoted by the community thus getting them fixed earlier. If your particular bug has low numbers you have a reference as to why it’s not being addressed in a timely manner. Companies have to give resources to places they get the most bang for the buck.

Not only would this keep Mikrotik accountable, but it would keep the community accountable.  Properly reporting bugs and reproducing them is a process. It takes effort on both the user and the developer. In the end, it makes for a better product.

I have the utmost respect for Mikrotik and their staff.  Several folks there I consider friends. I think, before growing pains get too out of hand some sort of additional feedback options would be helpful for the community at large. Mikrotik is getting there. Things like making bug fix versions and release-candidate versions available, along with changelogs has been a huge help for planning and just keeping up on what’s being addressed.

What prompted this was I had a client over the past weekend who started having OSPF issues. Many hours of troubleshooting later, and only talking to some other folks who were seeing the same issues, I was able to determine a specific RouterOS version was to blame.  Being able to attach data to a specific bug report, or having Mirkotik open up a new bug based on information I submitted would have been a great help to others.  A forum of blog post would have been too general. Forums posts also tend to bring out the “I am seeing that too” and they are not meeting the same conditions you are.

Mikrotik implement a bug tracking system! Bugzilla is even on GitHub.

How I learned to love BGP communities, and so can you

BGP communities can be a powerful, but almost mystical thing.  If you aren’t familiar with communities start here at Wikipedia.  For the purpose of part one of this article we will talk about communities and how they can be utilized for traffic coming into your network. Part two of this article will talk about applying what you have classified to your peers.

So let’s jump into it.  Let’s start with XYZ ISP. They have the following BGP peers:

-Peer one is Typhoon Electric.  XYZ ISP buys an internet connection from Typhoon.
-Peer two is Basement3. XYZ ISP also buy an internet connection from Basement3
-Peer three is Mauler Automotive. XYZ ISP sells internet to Mauler Automotive.
-Peer four is HopOffACloud web hosting.  XYZ ISP and HopOffACloud are in the data center and have determined they exchange enough traffic amongst their ASN’s to justify a dedicated connection between them.
-Peer five is the local Internet exchange (IX) in the data center.

So now that we know who our peers are, we need to assign some communities and classify who goes in what community.  The Thing to keep in mind here, is communities are something you come up with. There are common numbers people use for communities, but there is no rule on what you have to number your communities as. So before we proceed we will need to also know what our own ASN is.  For XYZ we will say they were assigned AS64512. For those of you who are familiar with BGP, you will see this is a private ASN.  I just used this to lessen any confusion.  If you are following along at home replace 65412 with your own ASN.

So we will create four communities .

64512:100 = transit
64512:200 = peers
64512:300 = customers
64512:400 = my routes

Where did we create these? For now on paper.

So let’s break down each of these and how they apply to XYZ network. If you need some help with the terminology see this previous post.
64512:100 – Transit
Transit will apply to Typhoon Electric and Basement3.  These are companies you are buying internet transit from.

64512:200 – Peers
Peers apply to HopOffACloud and the IX. These are folks you are just exchanging your own and your customer’s routes with.

64512:300 – Customers
This applies to Mauler Automotive.  This is a customer buying Internet from you. They transit your network to get to the Internet.

64512:200 – Local
This applies to your own prefixes.  These are routes within your own network or this particular ASN.

Our next step is to take the incoming traffic and classify into one of these communities. Once we have it classified we can do stuff with it.

If we wanted to classify the Typhoon Electric traffic we would do the following in Mikrotik land:

/routing filter
add action=passthrough chain=TYPHOON-IN prefix= prefix-length=0-32 set-bgp-communities=64512:100 comment="Tag incoming prefixes with :100"

This would go at the top of your filter chain for the Typhoon Electric peer.  This simply applies 64512:100 to the prefixes learned from Typhoon.

In Cisco Land our configuration would look like this:

route-map Typhoon-in permit 20  
match ip address 102  
set community 64512:100

The above Cisco configuration creates a route map, matches a pre-existing access list named 102, and applies community 64512:100 to prefixes learned.

For Juniper you can add the following command to an incoming peer in policy-options:

set community Typhoon-in members 64512:100

Similar to the others you are applying this community to a policy.

So what have we done so far, we have taken the received prefixes from Typhoon Electric and applied community 64512:100 to it.  This simply puts a classifier on all traffic from that peer. We could modify the above example to classify traffic from our other peers based upon what community we want them tagged as.

In our next segment we will learn what we can do with these communities.

Mikrotik RouterOS 6.34.6 released

Direct from Mikrotik

To upgrade, click “Check for updates” at /system package in your RouterOS configuration interface, or head to our download page:

What’s new in 6.34.6 (2016-Jun-06 08:37):

*) discovery – fixed identity discovery (introduced in 6.34.5);
*) log – fixed time zone adjustment (introduced in 6.34.5);
*) snmp – fixed snmp timeout (introduced in 6.34.5);
*) vrrp – fixed missing vrrp interfaces after upgrade (introduced in 6.34.5).

Mikrotik wAP first looks

The routerboard at the USA Mikrotik User Meeting (MUM) this year was the wAP. For the official specifications on this little gem visit here.  Some highlights of this AP.
-802.11 b/g/n
-Secure mounting
-802.3at POE
As you can see a great deal of thought was given into the included parts with this unit.  Mount, screws, poe, and even a thick paper template for drilling the wall and ceiling mount.


Whomever is in charge of package and documentation design at Mikrotik gets high marks in my book for this setup. Included is a little instruction sheet which has topics for first use, powering, booting, connecting are all included on the first page in a concise manner.  On the second page instructions on netinstall, bootloader, and even enabling CAPs mode are all explained.


At a street price of $45 for this model these have many uses.  Outbuildings, work shops, patios, and many other places where an AP needs a little protection from the elements, are all good deployment choices.

MTIN announces new pricing tiers

MTIN is happy to announce support tiers for our clients.  This allows us to grow, while still being in budget range of the smaller operators.  This is our first rate increase in over 3 years.  By breaking our rates into two tiers this allows us to grow our increasing client base while still being an affordable client. The price levels allow us to add additional resources, automation, and tools to bring better service to clients.

Tier I Support
Network/Server Work                               $97 per hour
Late night & Weekend support                 $125 per hour

Hourly Blocks
5 hours              $461   (5% discount)
10 hours            $899   (7% discount)
15 hours            $1310 (10% discount)

On-Site consulting services                      $700 per day plus expenses
On-Site tower work                                  $500-1500 per day plus expenses (job specific)

Tier1 emergency response times for Tier I customers with a time balance.
Normal working hours (2 hour maximum)
Late night and weekend (3 hour maximum)



Tier II Support
Network/Server Work                                $79 per hour
Late night & Weekend support                  $99 per hour

Hourly Blocks
5 hours                       $395
10 hours                     $790
15 hours                     $1067 (10% discount)

Tier2 emergency response times for Tier II customers with a time balance
Normal working hours (4 hour maximum)
Late night and weekend (5 hour maximum)



Contracts available
-Priority support
-Faster response times
-Late night & Weekend support rates don’t apply
-Access to backend monitoring and other services
Contact MTIN on details on contracts

Policy details

1.Late night and Weekend is defined as. 9PM-9AM EST MONDAY-FRIDAY & 8PM EST FRIDAY -9AM Monday. For West coast and customer in other time frames work can be schedule to meet your needs and not be charge for after hours.

2.All customers who don’t have pre-purchased time will be served on a best effort service. Priority will be given to contract customers, and then customers with a balance, and finally to “walk-in” customers.

3.All times stated are maximum times for response. Depending on workload, times are typically much less.

Lots of changes in RouterOS 6.34

Lots of changes in RouterOS 6.34
Some Standouts that will be of benefit to alot of folks I know
*) mipsle – architecture support dropped (last fully supported version 6.32.x);
*) btest – significantly increased TCP bandwidth test performance;
*) ssh – fixed possible kernel crash;
*) crs212 – fix 1Gbps ether1 linking problem;
*) tile – make sure that SFP rj45 modules that use forced 1G FD settings work correctly after system reboot;

What’s new in 6.34 (2016-Jan-29 10:25):

*) mipsle – architecture support dropped (last fully supported version 6.32.x);
*) dude – The reports of my death have been greatly exaggerated;
*) dude – dude RouterOS package added for tile and x86 (CHR) architecture;
*) dude – package included by default to all CHR images;
*) dude – initial work on dude integration into RouterOS;
*) bgp vpls – fixed initialization after reboot;
*) mpls – forwarding of VRF over TE tunnel stopped working after BGP peer reset;
*) ipsec – improved TCP performance on CCRs;
*) btest – significantly increased TCP bandwidth test performance;
*) winbox – fixed possible busy-loop on v2.x with latest 6.34RC versions;
*) cerm – allow to sign certificates from imported CAs created with RouterOS;
*) ldp – fix MPLS PDU max length;
*) net – improve 64bit interface stats support;
*) routerboard – print factory-firmware version in routerboard menu;
*) snmp – add oid from ucd mib for total cpu load OID;
*) winbox – add extra items automatically to multi-line fields if at least one of them is required;
*) winbox – implemented full ipv6 dhcp client;
*) winbox – update blocked flag if user changed blocked field in dhcp server lease;
*) mac-telnet – fixed backspace when typing login username;
*) sstp – allow ECDHE when pfs enabled;
*) lte – fixed info command for Cinterion EHS5-E modem;
*) fast-path – fixed kernel crash on on/off;
*) licensing – fixed that some old 7 symbol keys could not be upgraded;
*) ssh – fixed possible kernel crash;
*) console – fixed crash on creating variable with “?” in it;
*) chr – fix SSH key import on AWS;
*) crs212 – fix 1Gbps ether1 linking problem;
*) timezone – use backward timezone aliases;
*) lte – support serial port for DellWireless 5570;
*) lte – improved dhcp handling on interfaces that doesn’t support it;
*) ipsec – allow my-id address specification in main mode;
*) dhcpv6 client – fix remove when client reappears on restart;
*) default config – fix hAP lite with one wireless;
*) firewall – added inversion support for “limit” option;
*) firewall – added bit rate matching for “limit” option;
*) firewall – improved performance for “limit” option;
*) dhcpv6-client – fix ia lifetime check;
*) ipsec – prioritize proposals;
*) ipsec – support multiple DH groups for phase 1;
*) netinstall – fix apply default config;
*) tile – make sure that SFP rj45 modules that use forced 1G FD settings work correctly after system reboot;
*) wireless – added WPS buttons support on hAP and hAP ac lite;
*) upnp – added comment for dynamic dst-nat rules to inform what host/program required it;
*) webfig – recognize properly CHR;
*) chr – license fix for AWS and similar solutions;
*) arm – fix usb modem modules on ARM;
*) dhcpv6-client – fixed stopped state;
*) netinstall – sort packages by name;
*) firewall – do not allow to add new rule before built-in (reverted);
*) winbox – include FP in fast-path column names;
*) ipsec – fix phase2 hmac-sha-256-128 truncation len from 96 to 128
This will break compatibility with all previous versions and any other
currently compatible software using sha256 hmac for phase2;
*) ssh, ftp – make read, write user group policy aware;
*) tunnel – fix keep-alive (introduced in 6.34rc);
*) cerm – show last crl update time;
*) quicket – support CAP mode on all existing wireless packages;
*) wlan – add united states3 country;
*) fast-path – fix locking issue which could lead to reboot loop (introduced in 6.34rc20);
*) userman4 – try loading signup files from db path first;
*) sstp – allow to limit tls version to v1.2 only;
*) chr – make tool profile work on 64bit x86;
*) dhcpv6-server – added binding server=all option;
*) hotspot – added html-directory-override & recognize default hotspot user;
*) hotspot – fixed export of default trial user;
*) hotspot – fixed memory leak on https requests;
*) winbox – allow to specify amsdu-limit & amsdu-threshold on 11n wifi cards;
*) winbox – added multicast-buffering & keepalive-frames settings to wireless interfaces;
*) CHR – implemented trial support for different CHR speed tiers;
*) dhcpv6-client – fix add route/address;
*) usb – enable ch341 serial module;
*) lte – make sure that both LTE miniPCI-e cards are recognized;
*) winbox – show Common-Name of certificates in certificate list;
*) winbox – added units to PCQ queue fields;
*) net – do not break connection when interface is added to bridge;
*) hotspot – show cookie add/remove events in hotspot,debug log;
*) hotspot – allow static entries with the same mac on multiple hotspot servers;
*) hotspot – do not remove mac-cookie in case of radius timeout;
*) hotspot – added byte limits option for default-trial users;
*) ipsec – make sure that dynamic policy always has dynamic flag;
*) CAPsMAN – use CAP name in log when remote-cap is deleted (wireless-cm2);
*) hotspot – fixed login by mac-cookie when roaming among hotspot servers;
*) hotspot – add html-directory-override for read-only directory on usb flash;
*) hotspot – add uptime, byte and packet counter variables to logout script;
*) net – fix statistics counters jumping up to 4G;
*) firewall – SIP helper update for newer Cisco phones;
*) usermanager – fixed usermanager web page crash;
*) ipsec – fixed active SAs flushing;
*) hotspot – added option to login user manually from cli;
*) hotspot – fixed trial-uptime parsing from CLI to Winbox/Webfig;
*) lte – added support for multiple E3372 on the same device;
*) modem – added wpd-600n ppp support;
*) console – fixed incorrect disabled firewall rule matching to “invalid flag”;
*) dns – fix for situation when dynamic dns servers could disappear;
*) sfp – fix 10g ports in 1g mode (introduced in 6.34rc1);
*) CCR1072 – added support for S-RJ01 SFP modules;
*) trafficgen – fixed issue that traffic-generator could not be started twice without reboot;
*) dhcpv6-server – replace delay option with preference option.

*) winbox – show properly route-distinguisher for bgp vpn4;
*) winbox – show dhcp server name in dhcp leases;
*) ppp – make CoA work correctly with address-lists;
*) winbox – fixed tab names to correspond to console;
*) winbox – show only actual switch-cpu ports in switch setting combobox;
*) winbox/webfig – fixed version column ordering in ip neighbors list;
*) webfig – fixed switch port “default vlan id” has missing “auto” value;
*) webfig – fixed firewall connection-bytes option;
*) ipsec – fixed kernel failure after underlying tunnel has been disabled/enabled;
*) romon – allow to see device identity if it is longer than 31 character;
*) fastpath – show fp counters in /interface monitor aggregate;
*) bridge firewall – fix chain check (broken since 6.33.2);
*) bridge firewall – fixed crash when jump rule points to disabled custom chain;
*) smb – fix crash when changing user which has open session;
*) address-list – properly remove unused address-lists from drop-downs;
*) fetch – fixed closure after 30 seconds;
*) capsman – fix radius accounting stop message;
*) log – reopen log file if deleted;
*) packing – fix tcp/udp checksums when simple packing is used;
*) tile – fix ipsec freeze after SA updates;
*) upnp – fixed missing in-interface option for dynamic dst-nat rules;
*) tunnel – fix complaining about loop after ~248 days;
*) vrrp – make sure that VRRP gets state on bootup;
*) ppp – fixed rare kernel crash (introduced in v6.33);
*) ppp – do not allow empty name ppp secrets;
*) ssh – fix active user accounting.

MTIN introduces Mnet service for Mikrotik and Ubiquiti routers

MTIN is excited to announce our newest support offering, Mnet. Mnet allows customers using Milkrotik and Ubiquiti routers an option of a tiered support level on a per device basis. This allows customers a guaranteed support level at a fixed price. This is an enterprise level support option for critical infrastructure.

The way Mnet works is a customer purchases one of our tiered plans below. They register the serial number with us and we simply provide the paid level of support on that device. This support includes technical support on that device as well as the services included with the purchased Tier.

Tier I (Overwatch) $199 per year (only $16 per month)
This tier is designed for the user who needs the occasional support but wants to make sure things like backups and software are being looked after.

  • Basic Remote monitoring & notification of device
  • Software notification of upgrades and personalized recommendations on needed action.
  • Monthly configurations backup to online secured storage
  • Next business day support of issues.
  • Hardware replacement option available
  • Initial configuration review

Tier II (Operator) $399 per year (only $34 per month)
This tier is for the user who needs that extra bit of help when it comes to configuration and wants an extra set of eyes.
Tier II includes all of the Tier I services and adds

  • Weekly configuration backup via e-mail and online secured storage
  • Enhanced monitoring & notification of devices
  • Same business day support (6 hour maximum lead time)
  • Weekend and holiday support (6 hour maximum lead time)
  • Discount on consulting services

Tier III (Spec Ops) $599 per year (only $50 per month)
This tier is for absolute mission critical devices.
Tier III includes all of the previous tiers and adds

  • Same day business support (2 hour maximum lead time)
  • Weekend and holiday support (3 hour maximum lead time)
  • Weekly backups of configuration via e-mail and online secured storage
  • Quarterly review and recommendations on configuration



Do I have to get this on every device?
No, we recommend this on your critical routers or routers doing advanced services such as BGP or core routing functions.

Does this replace your normal consulting services?
No. This is an add-on to our consulting services. We find we have customers who need help with certain aspects of their network and this fills that gap.

Can I get quantity discounts?
Yes, contact us for a quote

I want to upgrade my router. How will this affect mNET?
We would simply transfer your support contract from the old device to the new one. Upgrade support is included.

What configuration support is included?
Technical support including configuration and troubleshooting is included on supported devices. Other devices can be included at our normal hourly consulting rate.

Do you make changes?
All changes are explained and signed off by customer before being implemented. Changes are done during an agreed upon maintenance window with a change management process.

How do I obtain support?
Customer is provided a login to the MTIN portal. Online tickets are the best method for opening a case. Telephone support is also included, but tickets are normally quicker.

How does the lead time work?
MTIN strives to meet customer expectations. Lead times are the maximum amount of time it will take. Some days this time may be measured in minutes, other times it may be longer.

Do you cover other devices?
Yes, we have plans for AirFiber, Mimosa, and other platforms.

Can I upgrade to a higher Tier?
yes, However it will take 3 business days for upgrades to process. During this time your Tier level will remain the same.

How is payment handled?
Payment is due at device registration.

Can I pay monthly?
No. If you need occasional support please see about hourly consultation services.

If you would like more information please fill out the form below.