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.
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.
During the first networking field day: service provider one of the big topics was EVPN versus VPLS. Arista has put a lot of work into their EVPN deployment and this has give then a ton of success in the data center. However, a large portion of the provider space, especially last mile providers, rely on VPLS heavily. This naturally led to discussion about Arista VPLS support.
I’m pleased to see that there is now basic support in EOS as of EOS 4.27.2F and more on the roadmap. Hopefully, we’ll see the off ramp, RFC8560, from VPLS to EVPN which was a hot button topic throughout the week.
In the release notes for EOS 4.27.2F it calls our basic VPLS support. So I took a look. Reviewing the new 4.27.2F manual I found support for LDP PWs on RFC4447 which is virtual private wire support. This also appeared to be in EOS 4.26 but not earlier. Thanks to Arista for providing more documentation on their support for RFC4762 – LDP signaled VPLS.
In the meantime lets review how this works:
mpls ip
!
mpls ldp
router-id 100.127.0.3
transport-address interface Loopback0
no shutdown
!
pseudowires
pseudowire TEST-PW
neighbor 100.127.0.1
pseudowire-id 1
mtu 1500
!
patch panel
patch TEST
!
patch TEST-PW-PATCH
connector 1 pseudowire ldp TEST-PW
connector 2 interface Ethernet3
!
You have to define the end point for the LDP signaling in the LDP configuration. The configuration requires an endpoint (neighbor), pseudowire-id, and mtu. Without all three of these the PW won’t establish.
Then tie the port you want to use the PW with a patch panel connector. In this case we tied ethernet3 to PW TEST-PW.
Everything that comes in on Ethernet3 will be pushed into the PW and on to the endpoint. Let’s verify that the signaling mechanism works:
arista-11#show patch panel detail
PW Fault Legend:
ET-IN - Ethernet receive fault
ET-OUT - Ethernet transmit fault
TUN-IN - Tunnel receive fault
TUN-OUT - Tunnel transmit fault
NF - Pseudowire not forwarding (other reason)
Patch: TEST, Status: Down, Last change: 0:26:17 ago
Patch: TEST-PW-PATCH, Status: Up, Last change: 16:35:05 ago
Connector 1: LDP neighbor 100.127.0.1 PW ID 1
Status: Up
Local MPLS label: 116384, Group ID: 0x0
MTU: 1500, 802.1Q VLAN request sent: -
Flow label capability: none
Supported VCCV CV types: LSP ping
Supported VCCV CC types: Router alert label
Neighbor MPLS label: 116384, Group ID: 0x0
MTU: 1500, 802.1Q VLAN request received: -
Flow label capability: none
Supported VCCV CV types: LSP ping
Supported VCCV CC types: Router alert label
PW type: 5 (raw), Control word: N
Flow label used: no
Tunnel type: LDP, Tunnel index: 1
Connector 2: Ethernet3
Status: Up
CE-1#ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 14/18/22 ms
Now we have a functional layer 2 link between the distance CEs.
An important note if you want to put this into production is you have to use service routing protocols model multi-agent which requires a reboot of your devices.
There are also some restrictions in vlan translation/passing which I will explore in a future post. Now let’s check out the basic configuration.
After reviewing the documents for LDP signaled VPLS we built the topology above. All 3 PEs are in the same mesh so the 3 CE routers are all layer 2 adjacent.
I probably made every mistake you could as I started building this but the CLI is pretty helpful in what is wrong.
arista-11#show vpls
VPLS: TEST-VPLS
VLAN: 10, 802.1Q tag: -
MAC withdrawal trigger for local interface going down: Y
Pseudowire group: MESH, split-horizon
MAC withdrawal trigger on pseudowire failure: N
MAC withdrawal propagation: locally triggered
LDP neighbor 100.127.0.1 PW ID 1 PW name ARISTA-10
Status: No remote, Interface: Pseudowire3.0
LDP neighbor 100.127.0.4 PW ID 1 PW name ARISTA-13
Status: CLI incomplete
I originally missed specifying the MTU on the CLI so it told me my configuration was incomplete. I thought this was pretty neat as it prevented me from going down a bunch of different paths to determine why my original build was broken.
arista-13#show vpls
VPLS: TEST-VPLS
VLAN: 10, 802.1Q tag: -
MAC withdrawal trigger for local interface going down: Y
Pseudowire group: MESH, split-horizon
MAC withdrawal trigger on pseudowire failure: N
MAC withdrawal propagation: locally triggered
LDP neighbor 100.127.0.1 PW ID 1 PW name ARISTA-10
Status: Up, Interface: Pseudowire1.0
LDP neighbor 100.127.0.3 PW ID 1 PW name ARISTA-11
Status: Up, Interface: Pseudowire2.0
CE-3#ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 11/14/17 ms
CE-3#ping 172.16.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 11/12/14 ms
CE-3#
If you need help with your deployment reach out to us at IP architechs.
