Juniper Lessons Learned Compilation

My experience with Juniper Networks and JunOS was never too deep, especially since I was trained in the Cisco world. Working for a VAR that sold Juniper gear and offered system services, I was a system engineer that knew enough about Juniper gear to get servers connected and off to the races. Fast-forward a few years, and being bored with system engineering/administration at my organization, an opportunity came up because of my Juniper experience to join the network engineering team and I grabbed onto it.JUNOSThis post is just a quick compilation of things I’ve learned about JunOS that I thought I’d share, be it good, bad, or maybe even ugly. Some of these things you can learn from the ‘Day One’ books, but I feel like some things just aren’t that clear for whatever reason.

Showing Juniper Configuration As Commands

Coming from the Cisco IOS command line world, I was always a little annoyed with the configuration of Juniper because it was in a dictionary/JSON type of format. I mean, it’s great for reading and breaking down configurations into a structured data format, but it always felt a little inefficient on display space, and if you need to make a quick change to copy-edit-paste the configuration, it’s a little bit of a pain.

Then I learned about the ‘display’ command, which opened up a few doors.

Typical Juniper configurations look something like this:

However, you can get your configuration as commands with by piping your ‘show config’ command to ‘display set’, like this:

Which gives you the above configuration like this:

You can then show all the interfaces, make a quick copy-edit-paste change, and be done. Personally, I like this better then the ‘load merge|replace|set terminal” method, but that’s just me.

Even cooler about this is that when you do this, you can pipe your ‘show config’ command to ‘display set’ and then to your ‘match “0/0/0″‘ statement to find the configuration you’re looking for and identify the stanza it’s in. Something like this:

Which, in the above example, which show you all configurations that include “0/0/0” in it, like this:

The other thing about the display command is that it also has a bunch of cool output formats that I think are interesting to look at (‘display detail’ sure is interesting, and ‘json’ or ‘xml’ sure is helpful).

Juniper Wildcard Ranges for Configurations

When you’re in edit mode and you’ve just come from the Cisco world, you’re probably wondering where the heck the ‘interface range’ command is. If you’re like me, you started using ‘interface-range’ statements and just assumed JunOS is just quirky and resigned to not having range commands.

Well, you’re in luck if you’re reading this because JunOS does have the same feature and the command is ‘wildcard range’.

In Cisco, you may be used to doing something like this:

With Juniper, it’s like this:

Commit Sync By Default on Virtual Chassis’d Systems

This is a small one, but I thought it was worth sharing. One thing on any virtual chassis’d switches/routers that you want to remember to do is a ‘commit synchronize’ when you’re committing configurations. However, I’d prefer to not have to type ‘sync’ and just be done with it so I can ‘commit and-quit’ super quick. The solution is simple; run/add this to your config:

Do one last ‘commit sync’ and then this is done automatically.

Juniper Has Rapid-PVST Interoperability

One of the issues my org has dealt with at our Juniper-deployed networks is that our Cisco routers completely block the VLANs for downstream ports when a loop is detected. Almost always it’s that a user has plugged their phone into two ports on the network, and since spanning tree was only set to the default configuration (RSTP) on our Juniper gear, these outages were somewhat frequent.

After doing some research and testing, I found out that Juniper has developed a protocol for rapid-pvst interoperability called ‘VSTP’. I’m still developing and ironing-out the details about our configuration, but here’s the base configuration we’ve done.

Of note, I’ve deleted RSTP because I don’t know the ramifications of keeping it in there (which Juniper notes is supported).

Also of note, if you choose to configure each interface individually instead of ‘interface all’, VSTP has an interface configuration limit of just over 300 ports (I found this out the hard way while trying to configure a 8-count virtual chassis stack). Juniper notes this somewhere in it’s documentation, but they don’t give the exact number and they just vaguely say there’s a limit because of processing load.

I plan on fleshing what I’ve learned with Juniper spanning tree in a future post.

No-More Using That Spacebar

Finally, here’s a super quick one. If you run a ‘show config’ and just need it to print out the configuration before a software update, pipe the command to ‘no-more’ and it will print out the entire configuration, much like setting your terminal length to 0. Command:

Final Thoughts

Don’t really have much else to say other than I’ve come to appreciate JunOS a lot more than when I originally learned it. Overall, I think learning Juniper has made me a better engineer because I’ve had to think about network configuration and protocols in a broader sense, much like how learning Linux made me a better Windows administrator.

From my initial experience going down the Python networking development road, Juniper certainly is easier to work with than screen-scraping with Cisco. NAPALM is certainly my tool of choice as of right now.

SNMP with Juniper, however, leaves something to be desired. For example I added MIBs and configured some sensors in PRTG, but I get weird issues with interfaces such as getting their ‘logical’ interfaces in the form of something like ‘0/0/0.0’, but missing the interfaces that actually work in the form of ‘0/0/0’.

Lastly, what I’ve learned working between Cisco and Juniper is that I just don’t think Cisco has any special sauce with access switching anymore. As a result, what Cisco (and Juniper and others) are doing is selling you a platform instead of just hardware now. You have to buy into a giant platform narrative instead of just letting hardware compete with other hardware.

Skill Atrophy

One of the greatest threats to a young IT professional is skill atrophy. You work hard at developing a skill set over a given period of time, and you even go so far as to earn a certification in such a skill set — and then you quit using it.

The old appropriate is appropriate here: “Use it or lose it.”

Recently while working at a site, and much to my frustration, my skills in router and switch configuration — even just layer 2 and 3 protocols — had started to atrophy because I hadn’t touch a device in five months — then bam! I’m setting up not just layer 5-7 devices, but I’m also setting up layer 2 and 3. I’ve been working so long in the higher layers that I started to forget basics in layer 2 and 3.

 

Layer 3 Switch

 

The hard part is that it was something rather ridiculous. It was a layer 3 switch, and turned the gateway port into a routed port instead of a switched port, thinking that I would separate out a server farm from the layer 2 network that it was attached to through that port. Nothing was getting DHCP requests on this switch and it was frustrating me to no end, not to mention I had to local techs looking over my shoulder and just standing there wondering what was going on! In the end, it was by getting help from my boss and co-worker that lead me down the road to figure out what I had been doing wrong.

So how does one prevent skill atrophy? The obvious answer is to practice, but that may not always be an option, especially if you’re in an environment where the work constantly changes and you’re insanely busy (that’s my excuse at least). Perhaps doing Packet Tracer simulations — for CCNA folks like myself — would be really helpful here.

Another idea is just good documentation, even trying to take a snapshot in time to see what you were doing. Copy your configs and annotate the configs to explain what the heck you were thinking — even encouraging this at your company so that other techs, or future techs, can get an idea of what’s going on.

Asking for help is always an option, especially if you’re really stumped. Time wasted can never be taken back (it’s a sunk cost), so realizing you’re failing bad early on can help mitigate future problems. To quote Freakonomics writer Steve Levitt, “Fail quickly.” However, at the same time, realize your failure is also a learning and/or reinforcement opportunity and will make you a better IT professional.

And of course, there’s also a good IT professionals google-fu, but you should be relying on that constantly, otherwise, are you learning any of this stuff?

All this being said, I’ve learned my lesson and I’m better because of it.