The Junos Operating System is turning 20 next year (the First Release was July 7, 1998 according to Wikipedia) and still to this day it includes what is, in my opinion, the most powerful command line interface available on a networking device.
But with the current trend in networking to move towards fully automated, API-driven, SDN-orchestrated, Jinja2 templated nirvana, you’d be forgiven for thinking that switches will all ship with no CLI at all.
I’m a bit more of a realist and while I’m completely onboard with the benefits of network automation, I (along with what I suspect are most other Network Engineers out there) also don’t want to have to punch out 400 lines of J2 template code every time I need to test out a new feature, or re-create a customer issue in the lab.
So to start the ball rolling in 2018 with a very unfashionable topic, I’ve decided to put together a list of lesser-known Junos CLI magic that I’ve picked up over the years from other engineers, customers and pure serendipity that might help you.
Protecting your assets
In the lab environment, or anywhere you are doing large scale automation it’s always best to err on the side of caution when making configuration changes.
To this end, I like to use the protect feature in Junos to lock specific sections of configuration that I don’t want accidentally (or deliberately) deleted - specifically management IPs, routes and last-resort local logins.
To implement protect, simply single out the sections of configuration you want to lock like so:
Now when you commit that configuration these sections of the configuration will be locked - observe:
In order to delete or change these statements now, you need to unprotect them, commit, and then delete them and commit again:
This should slow down the annihilation when your PyEZ automation script becomes sentient!
Parse like a Boss
Junos implements quite a few UNIX commands in the shell that are exceptionally useful when parsing log or configuration files.
For example: if you’re browsing through a configuration file and want to quickly move to a specific section of it, you can use / to perform a forward regex search eg: type show configuration and then /interfaces.
In the same manner, you can search backwards for a section you wish to return to using ? to perform a reverse regex match eg: ?system will take you back to the system stanza (or to the first match of the string system).
When it comes to logging, we all know how frustrating it is having to troubleshoot issues sifting through on-box syslog files that are filled with hundreds of unrelated event messages.
Well, along with the forward and backward regex matches described above, you can also update match and exclude filters in real-time to rapidly zoom in on precisely the entries you care about.
Here’s an example with a very verbose flow trace file on an SRX:
Firstly, it’s all double-spaced which is hard to read, so let’s just focus on lines with Jun in them:
Now, let’s start culling entries that don’t appear to be useful like the ones mentioning vector and mbuf:
As you can see - as you add more matches and exceptions, your logs will gradually be pared down to more useful information.
As with most Junos commands, you can chain these commands using pipes as well and in real-time:
will give you realtime log output from all daemons except alarmd and mgd.
And finally, don’t forget about </code> or reverse search in the CLI.
This allows you to do a quick regex search of your CLI history so you can find that long command you entered earlier without having to press up arrow 47 times!
Realtime location tracking
Well, sort of… Did you know that tucked away inside Junos is everybody’s favourite real-time traceroute implementation mtr?
It’s a fairly old version (v0.69) but the fact that you can run this from inside Junos is sometimes quite useful for looking at any instantaneous packet loss along a routed path.
To execute simply
and you’ll see some output like the following, updating in real-time.
Be advised that traceroute monitor is only available from within inet.0 though, which does limit it’s usefulness - if anyone from Juniper engineering is reading this - I’d love to see a routing-instance option added!
And speaking of refreshing, another feature that doesn’t get much attention is the refresh action that you can pipe commands to.
What this does is re-run your previous command at the interval you specify, and time-stamp the output for you.
This is super helpful when troubleshooting intermittent issues - the results can even be piped to a file.
Much better than standing by your console over night pressing Up-Arrow / Enter, and much less dangerous than setting up a drinking bird in your Data Centre.
And now for breadcrumbs
Another relatively unknown feature is configuration-breadcrumbs. This appeared around Junos 12.2 and displays the configuration hierarchy (breadcrumbs) of the currently displayed configuration output:
This is super useful if you’re examining a large configuration file on box and need to keep track of which stanza you’re under (especially subscriber detail on a BRAS, or deep configuration under a routing-instance)
To enable, you need to configure it under your login class:
and then log back in again.
Are you committed?
This is one that I was shown by a customer very recently:
When you perform a commit confirmed the configuration will be applied and then Junos will wait for a follow-up commit before it removes the rollback timer.
On clustered Junos deployments such as EX virtual chassis, or Branch SRX Chassis Clusters with large configurations, running this follow-up commit can take quite a bit of time as your configuration is re-checked and applied against each VC member, even though nothing is changing.
It is especially daunting when you commit confirmed for only a minute or so, and then realise your testing will actually take up all of this time.
It turns out that by running a commit check instead, Junos will re-validate the configuration (against the REs only) and then remove the rollback timer, saving what might be precious seconds or minutes during a change window.
That’s just the Tip of it
Well, that’s about it for this post - hopefully you’ve picked up at least one new trick that will make your Junos CLI-fu that bit stronger.
For even more CLI tips, Junos includes a whole bunch built in - type
for a random one, or
to read through them all independently - you can even give console/SSH users a tip of the day by adding the
I’ve been building and deploying Juniper SRX Firewall clusters for a good 6 years now and even managed to pick up a JNCIE-SEC along the way, but last week I stumbled across an interesting configuration feature when using LACP and Reth interfaces that I’d never seen documented before.
Let’s start with a quick primer on SRX Redundant Ethernet (Reth) Interfaces and LACP:
Firstly, one or more physical ports from each SRX chassis-cluster node are assigned to a Reth interface:
Under the reth interface we configure LACP:
Behind the scenes this creates two distinct LACP sub-LAGs, one from each physical SRX node to the downstream device:
option is so that each LACP sub-LAG is considered to be up while ever there is still at least one port active.
Finally we assign the Reth to a redundancy-group that specifies the “Primary” node on which interfaces in the Reth will be active by way of the
(higher being more preferred), and optionally
fails the RG back to the primary node when it becomes available.
Something that isn’t immediately obvious to newcomers is that given the above configuration, if both ge-0/0/4 and ge-0/0/5 are unplugged from the primary node, the minimum-links threshold will be crossed and the reth on the primary node will go down, however the redundancy-group will NOT fail over:
I will digress here for a moment and say that to this day, I still can’t think of a single reason why this behaviour is ever desirable. If you’ve got a topology that benefits somehow from completely losing a reth without failing over, I want to know about it! :)
Each redundancy group has an in-built Threshold counter which determines when fail-over to the secondary node will occur - this value is set to be 255 under normal conditions.
Looking at our redundancy-group again, we now add in the
statements, which specify a
against physical interfaces.
Now whenever any of the four interfaces listed above goes down, their
will be subtracted from the Redundancy-group threshold; when this threshold reaches 0, the redundancy-group will fail over and activate interfaces associated with reths associated with this redundancy group on the secondary node.
It should be noted that the physical interfaces being monitored don’t have to be members of a Reth interface associated with this redundancy-group.
You can see the results of this using the hidden-until-recently command
show chassis cluster information
In the example above, I’ve deliberately used a
of 128 so that a single link loss will not cause fail-over, instead requiring that both links to a node go down before failing over - this configuration achieves the same thing as configuring
in the LACP bundle, except that it actually causes the fail-over to occur in a redundancy-group.
This seems somewhat (wait for it…) redundant to me.
A better way
What I recently discovered however was that you can configure interface-monitor to monitor the Reth interface instead of the physical links that make it up eg:
With this deployed, if the LACP sub-LAG bundle falls below
, it is taken down as before, but now
will detect this and fail the redundancy-group over.
This also means that if you decide to scale the number of LACP ports up or down in the future, you don’t have to fiddle with interface-monitor weights.
As an added bonus, the interface-monitor now has a dependency on the downstream device to be an active LACP participant, rather than just monitor physical link status - think of it as free BFD!