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.
This 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:
interfaces {
ge-0/0/0 {
unit 0 {
family ethernet-switching {
interface-mode access;
vlan {
members 60;
}
}
}
}
}
However, you can get your configuration as commands with by piping your ‘show config’ command to ‘display set’, like this:
show configuration | display set
Which gives you the above configuration like this:
set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members 60
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:
show configuration | display set | match "0/0/0"
Which, in the above example, which show you all configurations that include “0/0/0” in it, like this:
set interfaces ge-0/0/0 unit 0 family ethernet-switching interface-mode access
set interfaces ge-0/0/0 unit 0 family ethernet-switching vlan members 60
set switch-options voip interface ge-0/0/0.0 vlan PHONES
set switch-options voip interface ge-0/0/0.0 forwarding-class expedited-forwarding
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:
int range g1/0/1-2,g1/0/4,g1/0/6
With Juniper, it’s like this:
wildcard range set interfaces ge-0/0/[1-2,4,6]
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:
set system commit synchronize
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.
protocols {
vstp {
interface all {
bpdu-timeout-action {
block;
}
}
vlan all;
}
}
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:
show configuration | no-more
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.