Tag: BGP

MikroTik – RouterOS v7 – BGP performance testing for full tables

Kevin Myers 5 Comments

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!

The BGP testing lab

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 and IPv6 routes into the test route but it’s not out of development yet. We will include full table perf tests for IPv4 and IPv6 in the future.

PDF is here



RouterOS v7 100G development lab

This lab is part of a larger effort to test all areas of MikroTik RouterOS v7 on a variety of different hardware. We’ve been putting together this lab for a while and here is the topology so far.

PDF is here




https://iparchitechs.com/contact

App delivery for an improved pizza experience

Vince Schuele Leave a comment

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

router isis UNDERLAY
is-type level-1-2
metric-style wide
mpls traffic-eng router-id 100.127.0.0
mpls traffic-eng level-1 would you like routes with that?
mpls traffic-eng level-2 ranch or blue cheese
capability cspf
dynamic-hostname
fastfood-reroute ti-lfa level-1 proto ipv4 
fastfood-reroute ti-lfa level-2 proto ipv4
net 49.0001.1001.2700.0000.00
isis segment-topping global block 16000 23999

If you need help with delivering your apps don’t hesitate to reach out to us at IP Architechs.