Cisco to MikroTik – command translation – OSPF

Kevin Myers 2 Comments

In the world of network engineering, learning a new syntax for a NOS can be overwhelming if you need a specific set of config in a short timeframe. The command structure for RouterOS can be a bit challenging if you are used to Cisco CLI commands.

If you’ve been in networking for a while, there’s a good chance you started 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 second post in a series that creates a Rosetta stone essentially between IOS and RouterOS. We plan to tackle  other command comparisons like MPLS, VLANs and basic operations to make it easier for network engineers trained in Cisco IOS to successfully implement Mikrotik / RouterOS devices.

Click here for the first article in this series – “Cisco to MikroTik BGP command translation”

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.

Using  EVE-NG for testing

In the last article, 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. For this article, we decided to use EVE-NG as it’s becoming more and more popular for network emulation.

Network for Basic commands

OSPF-topology

 

Cisco commandMikroTik Command
show ip ospf neighborrouting ospf neighbor print
show ip ospf interfacerouting ospf interface print
show ip ospf 1routing ospf instance print detail
show ip ospf databaserouting ospf lsa print
show ip route ospfip route print where ospf=yes
show ip ospf ribrouting ospf route print
show ip ospf border-routersrouting ospf area-border-router print
show ip ospf border-routersrouting ospf as-border-router print
Cisco(config)#router ospf 1/routing ospf instance
Cisco(config-router)#router-id 203.0.113.1/routing ospf instance set 0 router-id=203.0.113.2
Cisco(config-router)#network 203.0.113.1 0.0.0.0 area 0/routing ospf network add area=backbone network=203.0.113.2/32
Cisco(config-router)#network 203.0.113.128 0.0.0.7 area 0/routing ospf network
add area=backbone network=203.0.113.128/29
Cisco(config-router)#interface GigabitEthernet0/0
Cisco(config-if)# ip ospf network point-to-point
Cisco(config-if)# ip ospf dead-interval 4
Cisco(config-if)# ip ospf hello-interval 1
/routing ospf interface add dead-interval=4s hello-interval=1s interface=ether1 network-type=point-to-point

Examples of the MikroTik RouterOS commands from the table above

[admin@MikroTik] > routing ospf neighbor print

This is a quick way to show all the OSPF neighbors the router is adjacent to.

cisco-to-mikrotik-ospf-1

[admin@MikroTik] > routing ospf interface print

This command lists all of the interfaces configured for OSPF, costs, authentication and whether or not the interface is passive. Unlike Cisco, MikroTik’s default behavior is to dynamically create an OPSF interface when a network statement is added which is what the ‘D’ flag stands for.

mikrotik-to-cisco-ospf-interface

[admin@MikroTik] > routing ospf instance print detail

This command lists the details for all OSPF instances on the router including: router-id, redistribution settings, default metrics and filters applied in and out.

cisco-to-mikrotik-ospf-instance-detail

[admin@MikroTik] > routing ospf lsa print

This command lists all OPSF LSAs along with sequence number, originator and age.

cisco-to-mikrotik-ospf-lsa

[admin@MikroTik] > ip route print where ospf=yes

This command allows you to list all of the OSPF routes in the routing table. Unlike Cisco, RouterOS will list routes that aren’t active in the routing table instead of just in the RIB like Cisco.

cisco-to-mikrotik-ospf-ip route-print-where-ospf

[admin@MikroTik] > routing ospf route print

This is a quick way to show the routes that OSPF is aware of on the router, the state of the route, cost and the gateway/interface.

cisco-to-mikrotik-ospf-routing-ospf-route-print

[admin@MikroTik] > routing ospf area-border-router print

Using this command will print all of the ABRs and areas the router is aware of.

cisco-to-mikrotik-ospf-routing-ospf-area-border-router-print

[admin@MikroTik] > routing ospf as-border-router print

This command will list all ASBRs for the router.

cisco-to-mikrotik-ospf-routing-ospf-as-border-router-print

[admin@MikroTik] > routing ospf export

Here is an example of a basic MikroTik OSPF config with a few options turned on like a standard area defined as well as redistribution of connected routes.

cisco-to-mikrotik-ospf-export

More Cisco to MikroTik articles are on the way!

This article covers most of the common OSPF commands. Some of the more advanced config and commands including OSPF flitering, Virtual and Sham Links will be tackled in a separate article. MPLS and VLANs are also on the list. Stay tuned for more!

Preview: Networking Field Day Exclusive with Aruba (HPE) – The 8400 core switch

Kevin Myers Leave a comment

 

aruba-game-has-changed

Back to Silicon Valley!

As a network type, it’s hard not to be excited when heading to a Networking Field Day event. I joined then NFD club by attending NFD14 and have been hooked ever since.

Not only is it an honor and a privilege to be invited to an NFD event, the personal relationships that are forged in the larger TFD community are some of the most valuable I’ve ever had in my career.

This go around we’ll be visiting Aruba (A Hewlett Packard Enterprise Company) in Santa Clara to deep dive on the newest addition to the Aruba product line – the 8400 core switch.

A new face in campus town – the Aruba 8400

It’s been a while since anything exciting happened in the world of campus networking. It’s a steady segment for most vendors but nothing disruptive has really happened in the last few years.

And that’s not incredibly surprising. For better or worse, as long as campus networks aren’t broken in most enterprises, they are often neglected in favor of the data center and cloudy pursuits.

Aruba is touting the 8400 to increase automation and visibility in the campus core – both are areas that network engineering teams have traditionally struggled to implement.

Couple that with a brand new API enabled NOS that has built-in analytics and Aruba may have a serious claim on the ‘game changing’ campaign it has been running since announcing the 8400 in June 2017.

The 8400 quick specs:
  • 8 slot chassis (for linecards)
  • Provides up to 19.2 Tbps switching capacity (8.571 billion packets per second)
  • Supports a maximum of 256 10GbE (SFP/SFP+) ports, or 64 40GbE (QSFP+) ports, or 48 ports 40/100GbE (QSFP28) combination
  • Full 8400 data sheet is here

First impressions:

What I like

Speeds/Port Density – The speed/port density specs for the 8400 read more like a data center switch than a campus core which means even the largest campus networks will have plenty of available ports with up to 100 gig if needed.

Security – Encryption at wire speed is becoming more and more of an issue as new security and compliance requirements force network teams to treat private links that were previously trusted as untrusted. The availability of MACSEC on linecards is big plus.

Automation – In reading the product literature, one of the differentiating factors listed is the ability to automate manual tasks like the provisioning of network switches to support wireless access points. This is a task that can be fairly daunting in a network with a large number of switches and no automation. I’ll be interested to see how the ‘zero touch’ provisioning for APs that Aruba describes actually works.

Visibility/Troubleshooting – Enhanced visibility and troubleshooting tools are a welcome feature for any engineering team. Aruba has developed a Network Analytics Engine that is listed as being at the heart of this set of capabilities. Onboard network analysis modules have been tried before by other vendors with varying degrees of success and so it will be interesting to see what Aruba’s take is on built in analytics.

Virtual Switching Framework – As a designer of networks, i’m a big fan of leveraging link aggregation in my designs for path redundancy coupled with switches than can support multi-chassis LACP.  The 8400 supports Aruba’s Virtual Switching Framework which allows both chassis to work together in similar fashion to a switch stack which allows for a single LACP channel to contain links in two different chassis. While this isn’t a groundbreaking feature, it’s critical to competing in the campus core market.

Complete REST API – Aruba describes the REST based API in this blog post as having access to “every network function and state, both persistent and ephemeral, within the switch.” This opens up a world of possibilities for integration and automation into enterprise applications as well as automation/orchestration engines.

Initial questions I have for Aruba:

Code maturity – The Aruba OS-CX network operating system seems to be the heart and soul of the new switch. As with any new NOS, one of my first questions is around interop and bug testing. What interop testing has been done and what are the results from current field deployments?

Software licensing and support – Software/feature licensing and support can be a source of frustration fro enterprise clients. Understanding the software and support model that Aruba uses will be one of the initial questions that I have.

Depth of the L3 feature set – As much as we try to avoid complexity in the core, sometimes advanced features in OSPF and BGP are needed such as dynamic routing within a VRF or a complex set of REGEX values to build a route map for a BGP peer. One of my goals in attending this NFD is to better understand the capabilities of Aruba’s routing stack in OS-CX.

To disaggregate or not

Often the opinions we have on new technology are shaped by our daily work. As someone who is frequently engaged in whitebox integration, disaggregation has become more and more prevalant in my daily work.

I suspect the decision by Aruba to use a chassis to offer port density rather than a disaggregated leaf/spine architecture stems from the lack of demand by enterprises to use leaf/spine in the campus.

Chassis is what everyone is comfortable with and expects to implement when designing the campus core. As such, nobody in the world of disaggregated networking has taken aim at the campus from a software standpoint.

That said, it will be interesting to see if a small leaf/spine core is considered for future hardware iterations of the OS-CX family aimed at campus deployments.

More to come!

As I write this, I’m enroute to #NFDx and am looking forward to the presentation by Aruba so that we can deep dive and really understand what makes the 8400 tick and the problems Aruba is trying to solve.

Please tag me @stubarea51 on twitter with the #NFDx hashtag if you have questions you’d like to ask Aruba about the 8400.

Stay tuned!