[adrotate banner=”4″]

As we all patiently await the release of RouterOS (RoS) v7 beta, MikroTik has announced a change in the way RoS development is organized.  There will now be three different tracks of development:

Bugfix only – When a current build is released, only fixes to known bugs will be added to this branch of development

Current – Current release will contain bugfixes and new features

Release Candidate – The release candidate will remain the development build for the next “current” release.

Graphical Overview of the new development cycle

Image and notes below are from here

A small addendum: the Bugfix only will only contain verified fixes, and no new features. The Current release contains the same fixes but also new features and other improvements, sometimes also less critical fixes than in Bugfix. And finally the Release Candidate is more likely to a nightly build. We will not to intensive testing before publishing these, only quick check if upgrade can be done and if most features work fine.

Origin

The idea originally came out of this thread and after a flurry of positive commentary, it became a working practice shortly therafter.

We plan to make sub-version releases that only contain fixes and no new features.

For example, we would release 6.30 with some new features in FastPath. Then, if some issues are found, we would make 6.30.1 with only fixes and no new functionality. When we add a new option or feature, we would make 6.31.

6.XX.Y – only bug fixes
6.XX – fixes and feature changes

We could even make several fix-only releases in a row, if needed.

The idea is that you can upgrade to a sub-point release without risking new bugs, that could come with new features being added.

As the v6 cycle is coming to an end, there is simply no other ‘branch’ to put new features in, as v7 is still too ‘raw’. We could stop with the sub-point releases once v7 is mature enough for general use.

MikroTik download page gets a slight refresh with a new drop down

Thoughts

This a very positive change for MikroTik and will go a long way with customers and integrators to be able to select code based on the needs of the environment. This release cycle is very similar to other network vendors (Think of Cisco IOS General Deployment vs Maintenance Deployment) and works well.

Code selection is such a critical element to the stability of a network and it’s helpful to have the ability to load a RoS code that has been patched but without new features. It’s a bit early to tell as to how much of an impact this will make in the MikroTik community, but the results so far look promising. I’ve done upgrades on a number of CCRs and 2011 series routers from 6.30 –> 6.30.1 –> 6.30.2 bugfix only and haven’t seen any major stability issue s or other bugs when running on a BGP/MPLS/OSPF service provider network.

There was a lot of churn with bugs and working features breaking early on in 6.x and this change should help to avoid at least some of that upheaval when 7.x makes it to a “current” release.

[adrotate banner=”4″]

Here is Part 1 of the CCR1072-1G-8S+ review in case you missed it!

CCR1072-1G-8S+ Ultimate BGP Performance test

After many days of testing, Part 2 is finally here! Welcome to the stubarea51.net BGP gauntlet. We subjected the CCR1072 to different types of network torture stress testing. Continuing on from our initial review, we chose BGP as the first way to test the limits and capacity of the CCR1072-1G-8S+.

Here is an overview of our lab environment to test the new CCR

• CCR1072-1G-8S+
• CCR1009-8G-1S-1S+
• CRS-125-24G-1S+
• x86 VMs on ESXi 6.0 for upstream BGP peering
• (2) ESXi 6.0 Hosts with 20 Gb (4×10) connectivity
• Multimode 10 gig SFP+ using 50/125 OM3 fiber

All RouterOS devices were loaded with the latest stable code (6.30.1 at the time of testing)

Network Design of the StubArea51 LAB setup for BGP testing

For this series of testing, we took our two ESXi 6.0 hosts and built a number of VMs using RouterOS and Ubuntu to supply the 1.21 Gigawatts 3.6 Million routes we would need to beat up on the CCR1072 for a few days. If you’re not familiar with the RIPE Routing Information Service (RIS) project, go here to take a look at the routing tables we used. Because the route server does not load routes nearly as quickly as a router, we used a CCR-1009-1S-1S+ to take in a single copy of the 457,461 routes in the Palo Alto IX public BGP table (July 2015). Then we set up eBGP peerings between the CCR1009 and each of the 8 BGP upstream VMs to give the CCR1072 plenty of peers.  We also put two iBGP VMs in the same AS as the 1072 so we could test the route reflection capabilites of the CCR1072.

Concept of Testing in v6.30.1

One of the first things we wanted to test on the CCR-1072-1G-8S+ was how quickly it handled large BGP routing tables. It is probably a good idea to take a slight detour here and mention that in version 6 of RouterOS, the BGP process is not multi-threaded, so it is limited to one core. As such, there are improvements MikroTik is working on to make pulling in large BGP tables faster and more efficient. Here is that discussion in the MikroTik forums:

http://forum.mikrotik.com/viewtopic.php?t=69931

Next generation of code – RouterOS v7

After exhibiting and presenting at the USA MUM 2015 in Miami, we had a lot of time to talk to MikroTik and get some insight on what is happening with optimizing BGP in RouterOS. MikroTik has seen major BGP performance improvements in v7. I seem to remember a slide that was presented at the MUM with some specific performance numbers on v7 but I couldn’t find it. I did come across a slide from the 2014 MUM in Russia that talks about the routing improvements in v7:

This presentation on CCR Tips and Tricks by Janis Megis from that MUM is available here

Testing Results

Here are the results of the BGP testing we have done that list:

• How many peers are used
• How many total routes are taken in
• How long it took to fully converge
• VRF performance results (if applicable)
• Route-reflection performance results (if applicable)

Public BGP Table – IPv4 with 1 upstream peer (457,461 routes – 1 Minute 33 seconds)

Public BGP Table – IPv4 with 2 upstream peers (914,922 routes – 3 Minutes 25 seconds)

Public BGP Table – IPv4 with 4 upstream peers (1,829,844 routes – 7 Minutes 8 seconds)

Public BGP Table – IPv4 with 8 upstream peers (3,659,688 routes – 13 Minute 17 seconds)

Public BGP Table – IPv6

Unfortunately, we did not have a way to test a full IPv6 BGP table in our lab. We are working on enabling that for future testing and will update once we have some results.

BGP Performance in a VRF – IPv4 with 8 upstream peers (3,659,688 routes – 15 Minutes 45 seconds)

BGP Route Reflection – 2 clients (914,922 routes sent –  1 Minute 53 seconds)

Conclusion

The CCR-1072-1G-8S+ is a fantastic BGP core or edge router. It is able to take in a full table in just over a minute, and is able to take in two tables (which is the most common type of BGP peering deployment we see) in just over 3 minutes, which puts on equal or better footing with a Cisco ASR 1001/1002 at a fraction of the cost.

We see the CCR-1072-1G-8S+ as an extremely strong candidate to use as an Internet BGP edge or core router. A pair of the 1072 routers would also make great WAN aggregation routers for an enterprise data center. Considering most large enterprises don’t go much beyond 10,000 to 15,000 BGP routes in their private MPLS routing tables, the CCR1072 would be able to converge almost immediately and provide stable and scalable throughput to the core.

The next phase of testing we will move into involves throughput testing using iperf on the 1072 with 20 gbps, 40 Gbps and 80 Gbps load tests – we will use BGP/OSPF and MPLS/VPLS configurations to look at performance differences for different types of networks.

CCR-1072-1G-8S+ available soon @

http://www.roc-noc.com/mikrotik/routerboard/CCR1072-1G-8Splus.html

Stay Tuned!

Coming next – MikroTik CCR1072-1G-8S+ Review (Part 3 ) 20 Gpbs, 40Gbps and 80 Gbps routing performance testing over BGP/OSPF/MPLS.