Author Archives: Kevin Myers
Author Archives: Kevin Myers
When learning how to use OSPF with MikroTik, it can sometimes be difficult to understand how the different LSA types flow between areas.
In MikroTik’s OSPF documentation they briefly cover the LSA for OSPFv2 but don’t have OSPFv3 listed yet.
To better illustrate how the LSAs work, I created these graphical overviews for OSPFv2 and OSPFv3. When troubleshooting OSPF, it’s very helpful to understand which LSAs you should see in an area and how IPv4 and IPv6 differ.
Hope you find these helpful!
When troubleshooting OSPF in MikroTik, it’s often helpful to look at the LSAs to determine the root cause of an issue.
However, MikroTik’s LSA names don’t always match up to the language used in RFCs and other resources when trying to verify the behavior of an LSA is working as intended. This can make troubleshooting difficult.
These cheat sheets match up the lsa description for OSPFv2 and OSPFv3 in RouterOSv7 with the common LSA Type and number reference.
PDF links are listed below – hope you find this helpful!
PDF: https://stubarea51.net/wp-content/uploads/2024/06/ROSv7-OSPF-Fundamentals-SA51-LSA-Types-OSPFv2.pdf
MikroTik Routers and Wireless – Software
RouterOS continues to mature as we move through the versions in the teens.
When we transitioned between ROSv5 and ROSv6 in the early 2010s, it was right around this version numbering that we started to see production stability. By the time 6.2x versions came out, the general consensus was that v6 was ready for prime time. We are getting closer to that point in ROSv7 – depending on your use case.
Certainly, there are still issues to solve for advanced users like ISPs and Data Centers that need protocols like BGP, OSPF, IS-IS and MPLS, but simpler use cases seem to really be stabilizing with the last few months of releases.
Notable changes in this release:
*) bgp – allow to leak routes between local VRFs;
There are a few reasons this is a really important addition to ROSv7. First, it’s an issue that’s been on the roadmap for a very long time as noted in the Routing Protocol Overview section of MikroTik’s help docs. This is encouraging because it’s likely been one of the harder problems for the development team to solve given the length of time it sat open.
Secondly, it’s Continue reading
This is an article i’ve wanted to write for a long time. In the last decade, the work that we have done at iparchitechs.com with WISPs/FISPs in network design using commodity equipment like MikroTik and FiberStore has yielded quite a few best practices and lessons learned.
While the idea of “router on a stick” isn’t new, when we first started working with WISPs/FISPs and MikroTik routers 10+ years ago, we immediately noticed a few common elements in the requests we’d get for consulting:
“I’m out of ports on my router…how do I add more?”
“I started with a single router, how do I make it redundant and keep NAT/peering working properly”?
“I have high CPU on my router and I don’t know how to add capacity and split the traffic”
“I can’t afford Cisco or Juniper but I need a network that’s highly available and resilient”
Coming from a telco background where a large chassis was used pretty much everywhere for redundancy and relying on links split across multiple line cards with LACP, that was one of my first inclinations to solve the Continue reading
IPv6 adoption has really picked up in the last 12 months and MikroTik RouterOSv7 development is no exception. Dual stack networks are still the most common and easiest to initially deploy for carriers.
However, single stack networks with IPv4 as a service overlay are definitely on the horizon for MikroTik users now that MPLS can operate purely on IPv6.
Single stack networks are easier and cheaper to operate in the long run and are a natural evolution of dual stack networks as we begin to turn IPv4 off for underlay infrastructure.
There are a few different ways to distribute labels in IPv6 MPLS. SR-MPLS (less common and usually with IS-IS) and SRv6 are the other options besides LDPv6.
While I generally am in favor of SR-MPLS/SRv6 long term due to the protocol simplification and traffic management capabilities, having an IPv6 MPLS stack is a great starting point for MikroTik.
LDPv6 is defined by RFC 7552 and is fairly recent as it finalized in 2015. It generally operates in much the same way as LDPv4.
The most common use case among MikroTik users is more efficient subnetting of IPv4 and directly replaces LDPv4 for this Continue reading
Recently, we recorded a webinar to explain a design concept frequently used by iparchitechs.com to build and migrate WISP, FISP and Telco networks – separation of network functions. It centers around simplification of roles within an ISP network. It also explores the use of lower-cost commodity network equipment to maximize the service area for a given ISP footprint while meeting key requirements like scale, redundancy and capacity.
Webinar: Webinar Recording
Slides: Slide Deck
MikroTik has come a long way since the first release of RouterOS v7 beta.
One of the long-awaited features is improved BGP performance and the ability to leverage multiple CPU cores.
Testing BGP performance is a long process of lab and prod evaluation, so we decided to run some quick and basic tests to get a baseline.
When the CCR2216-1G-12XS-2XQ was released and MikroTik entered the world of 100G, we ordered some right away to test and just got them in the lab a few days ago – the results are below.
Hope this is helpful and look for more BGP perf tests in the coming months!
TLDR; 2.1 million routes learned and forwarding in 46 seconds and withdrawn in 44 seconds. This was tested under a 25 Gbps load on both routers with a cpu load of 12%.
Lab overview: The lab consists of (2) CCR2216 routers running ROSv7.2 stable connected to a ProxMox hypervisor that runs (4) Linux route generators and MikroTik CHRs (also on 7.2) acting as border routers. The specific connectivity is in the overview drawing below.
IPv6: We are currently developing a route generator that will inject IPv4 Continue reading
A few weeks ago, we recorded a webinar on deploying IPv6 for WISPs and FISPs. As IPv6 adoption continues to climb, developing an IPv6 strategy for design, deployment and system integration is an important step before subscribers begin asking for IPv6.
Webinar: click here
Slides: click here
PDF link is here
“How do I add redundancy?”
“How do I scale?”
“How do I reduce downtime and operational costs?”
These are questions that I get asked practically every day as a consulting network architect that designs and builds ISPs.
In most cases the answer is the same whether the ISP uses fixed wireless broadband, copper or fiber to deliver the last mile – separation of network functions.
This illustrated guide is intended to define the topic and create visual context for each function using a network drawing. It’s the first in a new series on this subject.
This topic is deep and there is a lot to unpack so this will be the first segment in a series of blog posts and videos covering function separation.
Large ISPs typically already embrace the philosophy of separating network functions, so the focus of this series will be to help new or growing regional ISPs understand the design intent and the challenges/costs of running networks that don’t separate network functions.
Routing filters have been a hot topic lately in the world of RouterOSv7. The first implementation of routing filters in ROSv7 was difficult to work with and documented in the two articles below:
MikroTik – RouterOSv7 first look – Dynamic routing with IPv6 and OSPFv3/BGP
MikroTik RouterOS – v7.0.3 stable (chateau) and status of general release
MikroTik then made some changes and opened up discussion to get feedback. I did a lot of work and testing using ROS 7.1beta7 which never made it to public release and was close to publishing the results when 7.1rc1 came out so this post will use that version.
Here is an example of the latest syntax in ROSv7.1rc1
CLI
### MikroTik RouterOS 7.1rc1 ###
/routing filter rule
add chain=dead.beef.101 rule="if (dst==200:dead:beef:101::/64) {accept}"
add chain=dead.beef.102 rule="if (dst==200:dead:beef:102::/64) {accept}"
add chain=dead.beef.agg rule="if (dst in 200:dead:beef::/48) {accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.101) {set bgp-local-pref 300; accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.102) {accept}"
add chain=bgp-out-v6 rule="if (chain dead.beef.agg && dst-len<128) {set bgp-local-pref 150; accept}"
Winbox
And the corresponding routes received Continue reading
MPLS/VPLS MTU math can be complicated and is always a struggle to unravel.
To make it a little easier and put it into a WISP context, I designed this cheat sheet on 8.5 x 11 (to print for those that actually trust printers) and used common WISP equipment like MikroTik routers, Ubnt and Cambium radios with real world MTU values.
The MTU values are displayed in layers to make it easier to see where each value fits.
PDF is here
These values are meant to be a starting point by representing the minimum values required for MPLS/VPLS with a single 802.1q VLAN tag.
In general, after going through hundreds of WISP migrations, I’ve found it to be easier to implement the minimum values required when working on a production WISP to identify the effective lowest MTU in the network.
Once the network equipment has been modified and has been running in a stable way on the minimum values, then higher values can be considered and implemented (now that the effective lowest MTU on the network is documented)
If you don’t already use it, the MIkroTik v7 BETA forum (forum.mikrotik.com) is a fantastic source of information
This is the million dollar question. Technically, it already has been for one hardware platform…
The Chateau 5G router originally shipped with a beta version of ROSv7 but was quietly moved to a stable version that’s developed specifically for that platform.
Because of the way MikroTik’s code repo works, this version can’t easily be added to the main download page and support provides the software:
ROSv7.0.3 Stable Download (!!! Chateau Only – will brick other hardware !!!)
https://box.mikrotik.com/f/7e3cad5779804d0b878d/?dl=1
It’s worth repeating MikroTik’s warning about using this on any platform other than the Chateau
If you’ve been around MikroTik for a while, then you know that version 7 has been in the works for a long time to add new functionality and address limitations of the older Linux kernel in ROSv6.
MikroTik recently Continue reading
Multi-Chassis Link Aggregation Group or MLAG is an idea that’s been around for a while.
It allows for the ability to form LACP channels across multiple physical switches.
Wikipedia shows a few different topology examples here
Vendor implementations are proprietary but the idea of MLAG was first mentioned in 802.1AX-2008 in 2008.
It first started to become popular in data center networking in the late 2000s
What makes the addition of MLAG to MikroTik’s RouterOS feature set notable is that it lowers the barrier to entry for this particular feature.
CRS 3xx switches are very inexpensive (starting at $149 USD) and may very well be the lowest cost MLAG capable hardware available on the market.
MLAG has been asked for by the MikroTik community a number of times and the most active feature request thread started here in 2020:
new feature request MLAG!!! – MikroTik
MikroTik added several version 7 beta releases in 2021 and included MLAG for all CRS 3xx series switches in 7.1beta6 on May 18th, 2021.
MLAG is fairly consistent across vendors with the need Continue reading
We are starting to see some larger footprints, speeds and power consumption from MikroTik and have a copy of the latest data sheet for the recently announced CRS404-96s-8q-rm switch
Data Sheet:
https://iparchitechs-my.sharepoint.com/:b:/p/kevin_myers/ERl4kYo6cOZPnFXKB9SRLgoBY0WGxbrH91OrWBNe9fIDFw?e=EnFYTZ
#AprilFools2021
In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly. Juniper is a popular option for service providers/data centers and is widely deployed across the world.
This is a continuation of the Rosetta stone for network operating systems series. In this article we will be covering multi-protocol label switching (MPLS) using label distribution protocol (LDP). We are sticking with LDP as MikroTik does not have wide support for RSVP-TE.
You can find the first two articles of the series here:
Juniper to MikroTik – BGP commands
Juniper to MikroTik – OSPF commands
While many commands have almost the exact same information, others are as close as possible. Since there isn’t always an exact match, sometimes you may have to run two or three commands to get the information needed.
We conducted utilized EVE-NG for all of the testing with the topology seen below.
Juniper Command | MikroTik Command |
---|---|
show ldp neighbor | mpls ldp neighbor print |
show ldp interface | mpls ldp interface print |
show route forwarding-table family mpls | mpls forwarding-table print |
show ldp database | mpls Continue reading |
In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly. Juniper is a popular option for service providers/data centers and is widely deployed across the world.
This is a continuation of the Rosetta stone for network operating systems series. In this portion of the series we will be covering Open Shortest Path First, OSPF, version 2 which is a popular interior gateway protocol (IGP).
You can find the first article of the series Juniper to Mikrotik – BGP Commands here.
While many commands have almost the exact same information, others are as close as possible. Since there isn’t always an exact match, sometimes you may have to run two or three commands to get the information needed.
We conducted all testing on EVE-NG utilizing the topology seen below.
JunOS Command | MikroTik Command |
---|---|
show ospf neighbor | routing ospf neighbor print |
show ospf interface | routing ospf interface print |
show ospf overview brief | routing ospf instance print detail |
show ospf database | routing ospf lsa print |
show route protocol ospf | ip route print where ospf=yes |
show Continue reading |
In the world of network engineering, learning a new syntax for a NOS can be daunting if you need a specific config quickly. Juniper is a popular option for service providers/data centers and is widely deployed across the world.
This is a continuation of the Rosetta stone for network operating systems series. We’ll be working through several protocols over series of posts to help you quickly move between different environments.
While many commands have almost the exact same information, others are as close as possible. Since there isn’t always an exact match, sometimes you may have to run two or three commands to get the information needed.
We conducted all of this testing utilizing EVE-NG and the topology seen below.
Juniper Command | MikroTik Command |
---|---|
show bgp summary | routing bgp peer print brief |
show bgp neighbor | routing bgp peer print status |
show route advertising-protocol bgp 172.31.254.2 | routing bgp advertisements print peer=peer_name |
show route receive-protocol bgp 172.31.254.2 | ip route print where received-from=peer_name |
show route protocol bgp | ip route print where bgp=yes |
clear bgp neighbor 172.31.254.2 soft-inbound | Continue reading |
If you missed it, take a look at MikroTik’s video on RouterOS v7 routing performance and changes.
One of the long awaited benefits of RouterOS version 7 is a new routing protocol stack that enables new capabilities and fixes limitations in RouterOSv6 caused by the use of a very old Linux kernel.
The new routing stack in v7 has created quite a buzz in the MikroTik community as lab tests have shown that it’s significantly more efficient in processing large numbers of BGP routes.
The ability to use MikroTik’s new generation of CCR routers with ARM64 to quickly process BGP routes is a blog post all to itself and we’ll tackle that in the future – however, the information below provides a quick look into the performance comparison between ROS v6 and v7.
The new routing stack also paves the way to add a number of features that have been needed for a long time like RPKI and large community support.
Using a lab based on EVE-NG, we’ll take a look at configuration changes and iBGP using the IPv6 AFI with OSPFv3 as the IGP for loopback/next hop reachability. Prior to 7.1beta2, this has been nonfunctional for years Continue reading
When MikroTik announced the CRS3xx series switches a few years ago, one of the most exciting aspects of that news release was the prospect of L3 forwarding in hardware on very inexpensive devices.
A quick review of the Marvell Prestera ASIC family showed a number of advanced routing, switching, MPLS and VxLAN capabilites.
Fast forward to 2020, where MikroTik has started to enable some of those features in RouterOS v7 beta.
Now we can finally take some of the CRS3xx switches and test their capabilities with L3 forwarding performance in hardware
Before getting into the testing, it’s probably helpful to review some of the basic specs and capabilities of the CRS3xx switch line.
Here is a chart from MikroTik that outlines ACL rule count, Unicast FDB entries and MTU size.
CRS 3xx model comparison
MIkroTik has been working on the development of the features listed below to offload into hardware.
For the tests in this article, we’ll be using IPv4 Unicast and Inter-VLAN routing.
Supported feature list
Currently, the following switches are supported.
For the testing in this article, we are using the CRS317-1G-16S+
Switches supported by 7.1beta2
The physical Continue reading
It seems like ages ago that we blocked out time in our schedules to fly to technical conferences and immerse ourselves with great people and content for an entire week.
In reality, it’s only been a few months but 2020 has made it seem like a lifetime.
However, those of us in tech are quick to adapt and virtual conferences are now a thing.
For the fixed wireless industry, in-person conferences are critical because most of the attendees are entrepreneurs.
For a small business owner in tech, going to a show is one of the best ways to evaluate content and business opportunities needed to stay competitive in a short amount of time.
Thankfully, due to some amazing effort and collaboration in the WISP industry led by Preseem and supported by WISPA, we are about to kick off the first virtual conference for the fixed wireless industry on July 28th, 2020.
An enormous amount of work has gone into planning and preparation to replicate the experience of an in-person technical conference as much as possible.
Kick off the registration process by visiting: https://wispvirtualsummit2020. Continue reading