Are you a Cisco IOS engineer? Are you confused as heck about how Juniper’s Junos operating system works? Then you’ve come to the right place! Welcome to this introductory post on Junos For IOS Engineers.
I’m Chris, a Juniper Ambassador and JNCIE #2981, and I’m “here” to “help” you “out”. I’ve taught Junos to a lot of folks in my time, and hopefully I’ve learned some tricks to help you understand what can initially seem like a complicated command line and configuration. My aim, by the end of this series, is to not only convince you that Junos is actually easy – but that once it clicks, it’s even easier than IOS.
ONE JUNOS, ONE CLI ACROSS ALL PRODUCTS! (WELL, KIND OF.)
Junos is over ONE BILLION* (*twenty) years old now. Wow. That’s older than the entire universe*! (*Not true.)
And it’s been impressively consistent that whole time, across many Junos versions, and across the entire product line of switches, routers and firewalls, ovens, toasters* and rocket-ships. (*This is actually true: Junos powers all the world’s toasters behind-the-scenes. When your toast tastes great, that’s because of Junos**.) (**Not true.)
What do I mean by consistent? I mean that regardless of whether you’re on old Junos or new Junos, regardless of whether you’re on a switch, router, or firewall, there’s an extremely high chance that you only need to learn one command across the entire product set.
This is particularly true when compared to Cisco, where you may potentially need to learn one command for a router, a different for an IOS switch, a different again for an ASA, yet another for NX-OS, and of course for IOS-XR too. I do not envy folks who go for a CCIE and have to learn multiple different operating systems and multiple commands to achieve the same thing!
With Juniper, regardless of whether you’re using a switch like an EX or QFX, a older router like an M, or T, a newer router like an MX, or a firewall like an SRX, there’s a really high chance that if the box supports the protocol, the actual CLI command will be the same across the entire suite.
Now, there’s definitely exceptions to that – as seasoned Junos engineers will be thinking to themselves as they read that last paragraph! Some of those differences are subtle, others are big. Some of them are small cosmetic tweaks, others are for new features, and others still are in order to make sure that there remains one command across the full product set. In a future post we’ll highlight some of these differences.
But the core philosophy and syntax of the vast majority of the CLI is almost identical to how it was from day one. The way you configure an interface, the way you configure OSPF, the way you commit your changes – chances are that if you were to read a book from 2004 on how Junos works, an absolute ton of it would still be relevant today.
MANY NETWORK ENGINEERS ONLY KNOW CISCO IOS
But even though Junos has been around for decades, I don’t think it’s controversial to say that statistically speaking, most network engineers are more familiar with the Cisco IOS command line.
I was the same for a very long time. In fact, I tried learning Junos back in 2012. I was self-taught, and I didn’t understand it. In fact, I’ll be entirely honest with you: I HATED Junos. And of course, I hated it because I didn’t understand it. The config file was utterly alien to me; the commands seemed long and complex. It wasn’t just a fear of the unknown – it looked downright weird. And as a nerd, I normally like things that are weird. But this? It made no sense to me.
Then, at the start of 2018, I started a new job and used Junos properly for the first time. I was very lucky to work with two people in particular who taught me why Junos works the way it does – and when it clicked, it was a revelation. It made so much sense! The elegance, the ability to review my changes before making them live, the ease with which I could actually GUESS what the right command would be with a brilliant consistency that I’d never experienced when using Cisco IOS, an operating system where I often found myself actively struggling to remember how to configure things.
I thought I loved networking when I only knew Cisco. But as soon as Junos clicked for me, going back to standard IOS seemed not only clunky, but unforgivable. If you’ve not got a proper commit and rollback in your operating system, miss me with it. Even later on when I started to learn IOS-XR, which does indeed have commits, I still didn’t get the same level of excitement as I did with Junos. It’s not just the CLI that I enjoy about Junos, it’s the philosophy.
WHY DO IOS ENGINEERS STRUGGLE WITH JUNOS?
I get fairly frequent emails from people saying they’d like to learn Junos. I always point them in the direction of some resources I found useful during my studies. I’ve even written posts on how to study for exams like Juniper’s Professional Service Provider cert, and their entry-level Cloud cert, to help folks along the way.
Still though, a fair number of those people come back and say that although they just about understand what’s happening in a Junos config, they don’t understand why it’s happening. They say that although they can kind of read a configuration file, they still find it difficult, and often they say they find it more complicated than IOS.
From my own experience back in 2012, I can entirely relate to why they feel like that.
It’s bit like someone who’s in the early stages of learning a second language. They’ve learnt the individual words in a sentence; they can translate them back to English on a word-by-word basis; but they don’t yet understand the grammar, so although they can just about understand it, they can’t speak it. They’ve probably never had a teacher that’s explained why the language clicks together like it does – and in the case of Junos, why it’s better than the way they previously knew.
There’s been a few attempts in the past to explain Junos to IOS engineers – taking the CLI knowledge and the networking knowledge they already have, and almost teaching Junos as a second language.
Indeed, the fantastic Junos Genius app and website host two such pieces of media. One is a great video Cert Prep series, and the other is a brilliant book by my Ambassador colleagues Martin Brown and Rob Jeffrey. You’ll see here a screenshot of the two of them, and they’re very much worth checking out.
What I often find lacking on the internet though, is one single post that I can point people towards which answers all the various quirks of Junos that IOS engineers don’t understand. What is inet.0? Why do configs looks weird? Why are there seemingly a million ways to save a configuration? And most importantly: WHY does it work like it does?
WHAT WILL THIS SERIES COVER?
That’s why I’ve started this new series on my blog, to explain exactly that – because when you understand what’s going on, I promise you that you’ll find Junos easier than IOS. In fact, once it clicks, I bet you money that you could guess your way through over 95% of the things you’d want to configure in Junos.
Here’s just a small selection of the questions this new series will be answering:
- Why do Junos configuration files look like they’re some kind of programming language?
- Why do some lines of configuration seem much longer in Junos than in Cisco IOS?
- Why do the actual commands I type to configure a box seem different to what’s stored in the configuration file?
- Why do I sometimes see VLAN interfaces and sometimes I see IRB interfaces? So much for consistency!!!!!!!!!!!!!!!!111one
- Why does there seem to be about twenty ways to save a configuration?
- Wait: you’re saying that I don’t have to type “enable” before I can go into configuration mode?
INTERFACES AND OPERATIONAL COMMANDS
- What’s all this “unit 0” and “family inet” business about on interfaces?
- Why do “show interface” and “show interface brief” not give me what I think they should give me?
- I’ve learned lots of “show” commands in Cisco IOS. Do I have to learn loads of different new commands in Junos?
PROTOCOLS AND TROUBLESHOOTING
- Why on earth are debugs called “traceoptions” in Junos?
- What on earth is this inet.0 routing table all about??
- I understand OSPF and BGP in Cisco. Show me the equivalent in Junos?
- I’m already confident in Quality of Service in IOS. But I just can’t work it out in Junos! And why do they call it Class Of Service?? Help!!
- Some interface stuff is done on the interface. But then sometimes it’s under OSPF, and sometimes it’s under RSTP… why isn’t the interface config in one place?!
There’s more than that, of course. But if you can think of anything you’re burning to have answered, let me know in the comments!
FOLLOW ME ON SOCIAL MEDIA TO SEE NEW POSTS!
These posts will assume little-to-no Junos knowledge. If that’s the kind of thing that sounds like it would be useful to you, follow me on Twitter to see when I make new posts in this series, and to also hear my terrible jokes and opinions about networking. Alternatively if you only want to have a 5% chance of seeing my new posts because the algorithm favours dreadful memes from recruitment consultants, follow me on LinkedIn.
I’ll aim for around one post a fortnight, but don’t hold me to that. I’m very busy. Busy doing what, you ask? Good question: I’m slowly-but-surely eating the world’s supply of chocolate. It’s a task that takes a lot of time, and I’m fully committed to it. But I’ll certainly do my best to make time for you.
Keep an eye out for Part 1, coming soon! (EDIT: Hey, since I wrote this intro post, Part 1 is now up! Click here to go straight to it!)