Cisco to MikroTik – command translation – BGP


In the world of network engineering, learning a new syntax can challenging especially if you need a lot of detail quickly. The command structure for RouterOS can be a bit challenging sometimes if you are used to Cisco CLI commands.  Most of us that have been in networking for a while got our start with Cisco gear and so it is helpful to draw comparisons between the commands, especially if you are trying to build a network with a MikroTik and Cisco router.

This is the first post in a series I’ve wanted to do for a while that creates a Rosetta stone essentially between IOS and RouterOS. We plan to tackle a number of other command comparisons like OSPF, MPLS and VLANs to make it easier for network engineers trained in Cisco IOS to successfully implement MikroTik / RouterOS devices. 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 plan to tackle a number of other command comparisons like OSPF, MPLS and VLANs to make it easier for network engineers trained in Cisco IOS to successfully implement Mikrotik / RouterOS devices.

Using GNS for testing

We used GNS3 to emulate both Cisco IOS and RouterOS so we could compare the different commands and ensure the translation was as close as possible.


BGP Commands 

Cisco CommandMikroTik Command
show ip bgp summary
routing bgp peer print brief
show ip bgp neighbor
routing bgp peer print status
show ip bgp neighbor advertised-routes
routing bgp advertisements print peer=peer_name
show ip bgp neighbor received-routes
ip route print where received-from=peer_name
show ip route bgp
ip route print where bgp=yes
clear ip bgp soft in
routing bgp peer refresh peer1
clear ip bgp soft outrouting bgp peer resend peer1
BGP-Cisco(config)#router bgp 1
/routing bgp instance
set default as=2
BGP-Cisco(config-router)#neighbor remote-as 2
/routing bgp peer
add name=peer1 remote-address= remote-as=1
BGP-Cisco(config-router)#network mask
BGP-Cisco(config-router)#network mask
BGP-Cisco(config-router)#network mask
/routing bgp network
add network=
add network=
add network=
BGP-Cisco(config)#router bgp 1
BGP-Cisco(config-router)#neighbor default-originate
/routing bgp peer
add default-originate=always name=peer1 remote-address= remote-as=1


Examples of the MikroTik RouterOS commands from the table above

[[email protected]] > routing bgp peer print brief

This is a quick way to get a list of peers/AS and their status


[[email protected]] > routing bgp peer print status

This is a command that will give you more detailed information about a BGP peer including MD5 auth, timers, prefixes received and the state of the peering as well as other info.


[[email protected]] > routing bgp advertisements print peer=peer_name

This will allow you to see what BGP prefixes are actually being advertised to a peer and the nexthop that will be advertised


[[email protected]] > ip route print where received-from=peer_name

This will allow you to see what BGP prefixes are actually being received from a peer and the nexthop that will be advertised


[[email protected]] > ip route print where bgp=yes

This will allow you to see what all BGP prefixes that are in the routing table – both active and not. This is a slight difference between Cisco and MikroTik since Cisco keeps BGP routes that aren’t in the routing table in the bgp table, whereas MikroTik routers keep all routes in the routing table with a distinction between active and not.


[[email protected]] >  routing bgp peer refresh peer_name

This will allow you to force the BGP peer to resend all prefixes without tearing down the peering – similar to a soft clear in Cisco IOS.


[[email protected]] >  routing bgp peer resend peer_name

This will allow you to force RouterOS to resend all prefixes to the peer without tearing down the peering – similar to a soft clear in Cisco IOS.


Configure BGP instance and peering

Here is a very basic BGP peering config with the minimum required to get BGP running for RouterOS. It includes setting the BGP AS, a peering and several networks to advertise.


Originate a default route to a specific peer

This will configure the peering to originate or advertise a route to the peer regardless of whether or not a default route already exists in the routing table. You can use the alternate default-originate=if-installed to only advertise a default route if one exists in the routing table.


More to come

There are so many commands to consider for BGP, we probably could have added close to 100, but we decided to list the commands we use the most often to start with and will be adding to the list of BGP commands as well as others like OSPF, MPLS and VLANs in future posts.


MikroTik – CCR1072-1G-8S+ – PPPoE testing preview – 30,000 connections and queues.


[adrotate banner=”5″]


Why we chose PPPoE as the next test

First of all, thanks to everyone for all the positive feedback, comments and questions about the CCR1072-1G-8S+ testing we have been posting in the last few months.  Even MikroTik has taken an interest in this testing and we have gotten some great feedback from them as well.

We received more questions about the PPPoE capabilities of the CCR1072-1G-8S+  than any other type of request. Since we have already published the testing on BGP, throughput and EoIP, we have decided to tackle the PPPoE testing to understand where the limits of the CCR1072-1G-8S+ are. This is only a preview of the testing as we are working on different methods of testing and config, but this will at least give you a glimpse of what is possible.

30,000 PPPoE Connections !!!!


Overview of PPPoE connections and CPU load


PRTG Monitoring

We have started using PRTG in the lab as it makes monitoring of resource load over time much easier when we are testing. Check it out as it is free up to 100 sensors and works very well with MikroTik

PRTG CPU Profile 



PRTG PPPoE connection count over time

It took us about 20 minutes to reach 30,000 connections…we are working on tuning the config to see if we can shorten the time it takes to build the connections. In the graph here, you can see it go form a 24 hour stable load of 30k connections donw to nothing as we prepare for a load test. At about 10:07 AM is when we started the full load test and you can see the time it takes to get to 30k.


More on the way!!!

This is just a small preview of our full PPPoE testing. We will be completing testing and should be publishing the results within the next week.