I have never installed any USB 3G/4G modem on my MikroTik RouterBOARD devices, despite most of them having a USB port available.  Finally I came across 2 situations where I had to deploy 4G USB modem as primary link at an event venue and as backup Internet connection at home.

I have 2 unused Bolt4G’s MF90 modems in unlocked state so I wanted to use them to save money from buying new modems.  I have many MikroTik RouterBOARD devices at my disposal, 2 hap ac lite, 1 hap ac^2, and 1 RB951Ui-2HnD.  This time I need to plug the modem into the hap ac lite and RB951Ui-2HnD running RouterOS 6.43.4 (the latest OS at the time).  There are tons of materials on MF90 and MikroTik routers because it was such a popular device at its time, which led me to think it should not be difficult to achieve.  It should be a walk in the park, so people say.  Turns out I was wrong.

MF90 drivers would not load on any of the MikroTik RouterBOARD devices I own.  I checked /system resources usb print and I could see the MF90 there.  It was recognised but there was no new interface in the /interfaces lte menu.  I checked the logs, restarted the modem, swapped the 2 MF90s, replaced the USB cable, rebooted the MikroTik devices, still nothing!  I googled further but I couldn’t find why it wouldn’t work, until I came across this and this.  Apparently one person have reported this issue to the MikroTik forum back in September 2016, yes 2016.  More than 2 years ago.  Guess what, nobody from MikroTik team responded to this poor guy (sger on forum.mikrotik.com).  sger mentioned that it had last worked for him on RouterOS 6.35.4 on his CRS125.  I immediately googled for that version of RouterOS (mipsbe package for the hap ac lite that I was using as a testing device) and downgraded the RouterOS.  Voila!  It immediately showed the lte1 interface, so sger is damn right about this.  Typical MikroTik bug I would say, I have seen a couple of times they lose older features to bugs like this.  I reached out to the kind guys at MikroTik support team, this time it went to Antons B.  One thing I like about MikroTik support is most of them know what they are talking about.  Another company who does well at this is cPanel.  Anyway back to topic, I knew I had to report this bug ASAP and they will gladly fix the issue because it was supported then and it should work ever since.

As always MikroTik support asked me to send my supout.rif file.  I had to disable my wireless package since 6.36 was the version where MikroTik introduced the new single wireless package, downgrading to 6.35.x would require me to disable wireless package before I could generate a supout.rif file for MikroTik support.  When it was enabled, the process to generate a supout.rif file would max out the CPU and end up crashing the process.  After sharing my supout.rif files on both the latest RouterOS 6.43.4 and 6.35.4, Antons came back with a new build of RouterOS 6.44beta32.  He told me to test this build and as mentioned above, it solved the problem flawlessly.  It took him only less than 3 days to come up with a new build.  This is why I love MikroTik, responsive and approachable.  If this were Cisco or Juniper, I don’t think I would be able to speak directly to their technical support team and most likely they would direct me to their partner’s support team which probably will never be able to solve the issue.  3 weeks later, MikroTik released 6.43.7 which is the latest stable build with the MF90 fix.

Now with the MF90 working, I get to achieve what I wanted to do.  However the MF90 has B08 firmware which is known to be locked to TDD2300 (B40). B05 firmware is said to support FDD2100 but it appears that nobody has done it (or rather share it publicly) so I ended up looking for new USB modems to take advantage of the FDD2100 band (where most of the national telcos operate their 4G services).  I did some research and Huawei’s devices seem to standout.  I considered XL Go Izi’s Movimax MV003 but I couldn’t find any reference stating that it’s usable on MikroTik (turns out it is working well with MikroTik after my colleague lent me hers to test).  Specs-wise it doesn’t say anything other than Qualcomm chip powered.   Since I’m not in a position to gamble right now, I took a safer choice in Huawei E5673.  Some references can be found on Google about it and it looks like a solid modem.  It is suitable for my first use case, however for the second use case I needed a AlwaysOn-like package for the backup Internet connection at home.  I considered Tri, but its performance on both 3G and 4G is just so so.  Telkomsel is expensive and thus is out of the question despite being the strongest candidate since they run both FDD2100 and TDD2300 LTE networks.  Indosat is probably the weakest of the top 3, so naturally it goes back to XL, my previous employer.  XL’s 3G and 4G services prove to be quite fast and reliable at home, but its long-term data package, branded XL Go Izi, requires XL Go-branded modems (E5573, E5577, MV003).  Since the recently purchased E5673 wouldn’t work with it, I ended up buying another one, an XL Go-branded Huawei E5573.  I did not want to risk buying E5577 nor MV003 because nobody has shared their experience getting them to work with MikroTik.  Anyway, after I received the E5573, I immediately started with a speedtest.  I got close to 30Mbps of download in the first attempt, 3X faster than my home FTTH Internet connection.  Now my backup is ready to pick up whenever the FTTH goes down.  Don’t hesitate to buy Huawei E5573, E5673, and Movimax MV003 if you wish to use them on MikroTik devices, I have tested all 3 and confirmed that they play nicely with MikroTik RouterOS!

I have two separate Metro Ethernet links (via fiber optic) from the datacenter to the NOC. Each link is 10Mbps. I need to utilize both links (bonding) and make sure sure that if one of the links goes down (redundancy), I won’t lose half of my packets. Bonding and redundancy are my goals.

Initially I tried Cisco Catalyst’s EtherChannel feature to accommodate this need since I learned about EtherChannel when I was doing my CNAP. Unfortunately EtherChannel cannot fit in this scenario due to my Metro Ethernet provider’s network setup. They use Cisco Catalyst 3750 switches to aggregate customers links from each POP to their headquarters. My first attempt was to establish trunk mode EtherChannel (802.1q) with Cisco Catalyst 2950 on one side and Cisco Catalyst Express 500 on the other side. Later I noticed that this is not doable since trunking requires MTU size to be larger than 1500 (1504) when my provider strictly limits MTU size to 1500 and negotiation between my 2 switches to establish trunking wouldn’t work since my switches’ BPDU packets are “intercepted” by my provider’s switches. Basically my Cisco switches were trying to establish a VLAN trunk with my provider’s directly connected switches when my switches are  supposed to be negotiating to each other.

I consulted a few experienced people including an employee of the provider, and they told me to use access mode EtherChannel instead of the trunk mode EtherChannel. This is not possible with Cisco Catalyst Express 500, which only offers trunk mode EtherChannel. I bought a Cisco Catalyst 2960 to replace the Cisco Catalyst Express 500 hoping that access mode EtherChannel would work, it didn’t. Even if it did work, it wouldn’t be aware of link state changes since my switches do not connect directly to the fiber cables. There is a fiber-to-ethernet bridge for each side of each link, so my switches will always detect both links as always up as long as the bridges are up.

Since link states cannot be used as a measurement in this scenario, I had to find another way. MikroTik RouterOS offers not only bonding feature, but fail-over mechanism too! The fail-over mechanism uses ARP packets to detect link failures, it is far from perfect but at least it works.

I will add examples later, but for now have a look at this. Hopefully I will discuss EoIP and EoIP over PPTP too.

References:
http://www.mikrotik.com/testdocs/ros/3.0/interface/bonding.php