One of the common questions asked by MikroTik users is how to go about upgrading from ROSv6 to ROSv7.
Before upgrading, always make sure:
– The config is backed up using ‘export’ and ‘backup’ and the files have been moved off the router – Console access is working (if applicable) – A method to netinstall is available in case the upgrade fails for any reason
Understanding config migration
MikroTik added a helpful chart to the support docs that shows what config is automatically upgraded and what needs to be manually adjusted.
BGP config migration has gotten better in the last few versions of v7. For the most part, it works without intervention but occasionally config will need to be removed and readded or edited.
Note the changes below to the structure of BGP menus and peerings as it has changed.
OSPF has come a long way in RouterOS v7 and is stable as well as interoperable with RouterOSv6. Interface templates have replaced network statements to advertise prefixes and form neighbor adjacencies, so be sure to look in that menu after upgrade to work with network statements in v7. Upgrading to v7 for OSPF normally works without issue or intervention.
MPLS is still a work in progress. Like the other protocols it has gotten better but still may need adjustments since it now includes the AFIs for IPv4 and IPv6 with LDP. Be sure to review the syntax pre and post upgrade as well as the operation state and be prepared to delete and re-add the configuration as needed if MPLS is not functional post upgrade. In general, MPLS and VPLS works between ROSv6 and ROSv7
Routing filters are also a work in progress. Most of the functionality and config upgrade works now when moving to v7 but the context sensitive help and tab complete is still being developed and filled in.
Understanding how the MikroTik support process works and how to ask for help can save a lot of time and frustration when you need assistance with features, configurations, hardware or potential bugs.
MikroTik Support…where do I start?
There are a number of ways to get assistance with MikroTik devices and software including: Jira ticket support, documentation, forums, Reddit, Facebook, distributors and professional consulting. One thing to keep in mind for all correspondence with MikroTik is they are based in Riga, Latvia which is GMT+3 in the spring/summer and GMT +2 in the fall/winter.
Current time in Riga, Latvia
As RouterOS Version 7 was released in Beta, MikroTik began moving to Confluence for documentation instead of the Wiki.
Prior to 2020, MikroTik support used e-mail ticketing to work issues which made complex issues a little harder to work on as the chain of discussion was sometimes difficult to follow.
Move to Jira
MikroTik migrated to Jira in 2020 which improved the support experience.
The key to understanding how to interact with MikroTik support is much like the advice for the forums. The more complete and well documented your ticket is, the better chance you have of getting a resolution.
The most important part of opening a ticket is to test the issue you’re experiencing on all versions of RouterOS 6 or 7 (Long Term, Stable, Release Candidate, Beta) and obtain a supout.rif for each of them.
This is very important as it will minimize a follow up e-mail from MikroTik support asking you to upgrade and then test again.
Tips for opening and managing a ticket
Provide detailed information.
– Description of the issue and the steps to repeat it.
– Network drawings.
– Configurations of other devices (if relevant)
– Packet captures (can be very helpful to identify and correct bugs
Be aware of the time difference between where you are and MikroTik (Riga, Latvia) – If you send and respond to support tickets during hours that MikroTik is awake and working, you’ll sometimes see faster responses but there is no guaranteed response time.
Waiting for bug fixes
Understand the limitations of fixing issues in RouterOS – If something can be fixed quickly, MikroTik is pretty good about getting it fixed and released.
Some issues can be patched easily and MikroTik will put them in the list for a future RouterOS release.
Some issues take longer to patch due to complexity and may be a while before they can be tested and released.
Certain issues cannot be fixed due to limitations in the Linux kernel and MikroTik will usually tell you if this is the case although with RouterOS 7 now released, this may happen less often than it did with RouterOS 6.
MikroTik Distributors can be a great source of support for assistance with setup and configuration as well as issues with hardware.
If you suspect that you have a hardware issue that might require an RMA, try a netinstall first to see if that corrects the issue and if it doesn’t, work with your distributor to replace the device.
It’s been a while since we started work on one of our newest projects. We have been trying to solve a problem in app location. It all came from the notion that Little Caesars know where my pizza is, so why can’t the network resolve where the app is? We also thought it would be novel use of Anycast because the app can be anywhere.
So, what problems specifically have we solved using this design? Intent based gateways are a signaling mechanism allows the apps to be delivered along with the pizza. As we can see app Buffalo Wings can reach both the intent based gateway and Fried Pickles using TI-LFA, which strips the fat bits before they reach the gateway. Our unique caching solution using Tupperware, which are stacked in K8s, allows for the apps to be delivered in a bursty nexthop specific competitive manner. This has proven to keep the apps warm within the physical layer.
In our example, the Delivery Center Interconnect, we are doing an east to west Multi Pizza Layered Service that can drop the apps with full BTU into any of the regions. The apps are unaware of the topping layer and rely on layer 2 media skipping protocol to travel between regions. As you can see, pineapple pizza is restricted to the west security zone because its traffic is otherwise discarded. Flows between Brooklyn and deep dish can be maintained because the overlay is based on ZeroTabasco.
A full mesh is achieved with the IGulP maintained by IS-IS. In this example a choice of which app is being forced so FFR can redirect service when the apps fail to reach the intent based gateway