FIVE BRILLIANT JUNOS TIME-SAVERS YOU MIGHT NOT KNOW ABOUT

Bradley Pitt. William Smith. Thomas Hanks. Leonardo Dee Car-Pario. What do all these ‘slebrities have in common? That’s right: they all personally re-twittered this recent tweet of mine on the popular micro-blogging website, Friends Reunited.

In this tweet, I shared a cool Junos command that makes your job a billion times easier. The tweet seems to get quite a lot of love, which makes me think that there are many engineers who don’t know just how many awesome tools Junos offers them.

See, it turns out that Junos is packed full of stuff which will improves your job and your life. But if you’ve only learned Junos on the job, in the heat of the action, then you might not get a chance to learn anything beyond what you need to get the job done there and then. Show, set, delete – these are the standard commands, but there’s so much more than this.

In fact, Junos has some fiercely powerful CLI secrets. With one single command you can manipulate your configuration like a grand maestro conducting an orchestra, or an international gangster making two hundred crimes happen all at the same time.

So, in this post I’ve rounded up a few of my favourite tips and tricks that will turn your job form a chore into a joy. These are some serious time-savers, so don’t tell you boss about them. Share them with colleagues, but make sure to set the expectation with your manager that it will take just as long to get the job done as it ever did. That way, you can use the immense time saved to take a five-hour lunch break.

 

COPY CONFIGURATION WITH ONE COMMAND

This is actually the command that inspired this post, from the tweet I mentioned a moment ago. It was surprising to me just how few people knew this existed, an I’m sure you’re going to love it.

Imagine you had an interface with a load of configuration on it. Perhaps it’s a physical interface, let’s say ge-0/0/9, with dozens of sub-interfaces, each with its own VLAN tag, a description, and a load of other config too.

Imagine that you wanted to copy this configuration to a second interface, perhaps ge-0/0/8. How would you go about doing this?

Well, you’re a network engineer, so of course you would do a “show configuration interface ge-0/0/9 | display set”, press space bar a few times to show all of it, copy the configuration, paste it into Notepad, edit each instance of ge-0/0/9 to instead be ge-0/0/8, copy it out of Notepad, and then paste it back into the CLI.

That’s not bad. But, there’s a better way – you can achieve all of this with one single command.

If you want to replicate the configuration on a new interface, this one command will do the trick:

copy interface ge-0/0/9 to interface ge-0/0/8

Look at that! This one command created all that extra configuration. Job done!

Here’s an example, with only two sub-interfaces just to show you the point. Below you can see that there is no config on ge-0/0/8, while there is plenty of config on ge-0/0/9:

root@vMX_6> show configuration interfaces ge-0/0/8

root@vMX_6> 

root@vMX_6> show configuration interfaces ge-0/0/9
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 10 {
    description "Compu-Global-Hyper-Mega-Net VLAN 10";
    encapsulation vlan-bridge;
    vlan-id 10;
    family bridge;
}
unit 20 {
    description "Compu-Global-Hyper-Mega-Net VLAN 20";
    encapsulation vlan-bridge;
    vlan-id 20;
    family bridge;
}

Let’s copy the config over:

[edit]
root@vMX_6# copy interfaces ge-0/0/9 to ge-0/0/8

The result?

[edit]
root@vMX_6# show | compare
[edit interfaces]
+   ge-0/0/8 {
+       flexible-vlan-tagging;
+       encapsulation flexible-ethernet-services;
+       unit 10 {
+           description "Compu-Global-Hyper-Mega-Net VLAN 10";
+           encapsulation vlan-bridge;
+           vlan-id 10;
+           family bridge;
+       }
+       unit 20 {
+           description "Compu-Global-Hyper-Mega-Net VLAN 20";
+           encapsulation vlan-bridge;
+           vlan-id 20;
+           family bridge;
+       }
+   }

Marvellous! If you’ve got a lot of layer 2 interfaces, and you want to replicate an interface’s entire config to another interface, this is a great command to achieve very fast results.

 

CHANGE LOTS OF CONFIGURATION WITH ONE COMMAND

Now let’s imagine that instead of copying, you want to change some configuration.

This time, imagine that ge-0/0/1 is a core interface in your network, but  you suspect that it’s faulty.

What you’d like to do is simply unplug the cable in this interface, and plug it into ge-0/0/2 instead to see if the problem goes away. You want to run this new interface for a few hours, to get a real good feel for the results, and as such you want to do more than just copy the IP address to this new interface, and delete it from the old one – you want to also edit any mentions of this interface throughout the enitre config:

root@vMX_6> show configuration | display set | match ge-0/0/1
set interfaces ge-0/0/1 description "CORE: To vMX_1"
set interfaces ge-0/0/1 mac 00:00:00:01:06:01
set interfaces ge-0/0/1 unit 0 family inet address 10.1.6.6/24
set interfaces ge-0/0/1 unit 0 family iso
set interfaces ge-0/0/1 unit 0 family inet6
set interfaces ge-0/0/1 unit 0 family mpls
set protocols rsvp interface ge-0/0/1.0
set protocols mpls interface ge-0/0/1.0
set protocols isis interface ge-0/0/1.0
set protocols ldp interface ge-0/0/1.0
set protocols lldp interface ge-0/0/1

As you can see, there’s all sorts of protocols running on ge-0/0/1, and they all need to be changed. MPLS, RSVP, LDP, LLDP, and IS-IS are all running on this interface, and it all needs moving.

If it was just the interface, then perhaps we could have used the last trick we saw – we could have “copied’ ge-0/0/1 to ge-0/0/2, and then deleted ge-0/0/1. But that won’t work here: all the other protocols will still refer to the old interface.

Does it sound tricky? Well, I’ve got good news for you Timothy: it’s actually astonishingly easy. In Junos you can use the following command to replace any string of text in the configuration with something else:

[edit]
root@vMX_6# replace pattern ge-0/0/1 with ge-0/0/2

As the command suggests, this replaces every single instance of ge-0/0/1 in the configuration with ge-0/0/2. If you didn’t know this one already, then prepare to have your Junos experience transformed.

If you replaced everything manually there’s every chance of a mistake from missing something. By contrast, this one command takes care of everything. Take a look below, and notice everything related to ge-0/0/1 being removed, and replace with new config for ge-0/0/2:

[edit]
root@vMX_6# show | compare
[edit interfaces]
-   ge-0/0/1 {
-       description "CORE: To vMX_1";
-       mac 00:00:00:01:06:01;
-       unit 0 {
-           family inet {
-               address 10.1.6.6/24;
-           }
-           family iso;
-           family inet6;
-           family mpls;
-       }
-   }
+   ge-0/0/2 {
+       description "CORE: To vMX_1";
+       mac 00:00:00:01:06:01;
+       unit 0 {
+           family inet {
+               address 10.1.6.6/24;
+           }
+           family iso;
+           family inet6;
+           family mpls;
+       }
+   }
[edit protocols rsvp]
+    interface ge-0/0/2.0;
-    interface ge-0/0/1.0;
[edit protocols mpls]
+    interface ge-0/0/2.0;
-    interface ge-0/0/1.0;
[edit protocols isis]
-    interface ge-0/0/1.0;
+    interface ge-0/0/2.0;
[edit protocols ldp]
-    interface ge-0/0/1.0;
+    interface ge-0/0/2.0;
[edit protocols lldp]
+    interface ge-0/0/2;
-    interface ge-0/0/1;

Very nice indeed!

 

APPLY-FLAGS OMIT

A decent configuration can quickly become quite large. When this happens, there are often large sections of the config that you rarely, if ever, care about.

For example, you might have some long firewall filters configured which rarely change, and which you rarely want to look at. In that case, it can be quite a chore to have to hit the space bar thirty times to get past a very long firewall stanza, to get to the next bit you’re interested in.

That’s where apply-flags omit comes in.

This is a hidden configuration command (which means you can’t tab-complete it, you have to type it manually) which you can add to pretty much any part of the hierarchy, anywhere in the configuration. When you add it, that part of the configuration is hidden from the average “show configuration” command. Observe:

[edit]
root@PE-2# set firewall apply-flags omit

Usually when you read a Junos configuration, you’ll see the policy-options stanza, then the firewall stanza, then the routing-instances stanza. However, when you add this command above to the firewall stanza, things change slightly. In the output below I’m looking at a full configuration. You can see from the {snip} that I’ve cut out most of the config, to skip straight to policy-options:

root@PE-2> show configuration
{snip}
policy-options {
    policy-statement LOAD_BALANCE {
        then {
            load-balance per-packet;
        }
    }
}
firewall { /* OMITTED */ };
routing-instances {
    BLUE {
        instance-type l2vpn;
{snip}

Do you see how the entire firewall stanza is now hidden? This is supremely helpful when you have lots of devices with large chunks of identical configuration that you frequently find yourself skipping over!

You can add this flag anywhere in the hierarchy, which means that you could also add it to protocols, to policy-options, or anywhere. You can even add it to individual policies or firewall filters, if there are certain ones that you’d like to hide.

Don’t worry though – this configuration isn’t hidden forever, and there’s three ways that you can once again see the hidden configuration if ever you need to:

• In this particular example, “show configuration firewall” will show the configuration, because the omit command was applied at the firewall stanza. In other words, if you do a “show config” specifically on the stanza that is hidden, you can then view it.
• “show configuration | display set” will always show everything. In other words, nothing is omitted when you view things in set format.
• Finally, “show configuration | display omit” will also show you everything, in hierarchy format.

As you can see, it’s very easy to see the hidden config. It’s well worth looking at your standard templates and thinking about whether there’s any config that you only look at like 5% of the time. If there is, it’s a prime candidate to be omitted.

 

SAVING MASTER CONFIGS TO EASILY ROLL BACK TO

When you’re mucking about in a lab, it’s nice to have some master configurations that you can easily deploy.

For example, maybe you’ve got a topology like my Famous Ten Router Lab (made famous due to its celebrated performance as Claudius in an off-Broadway production of Hamlet last year). It’s great to just build a topology once, and then deploy different configurations to those routers so that you can immediately play with different technologies, without having to constantly re-configure everything. Perhaps you have a base config for OSPF, one for IS-IS, one for RSVP, one for Segment Routing, and so on. The ability to easily switch between them is a very attractive one.

Junos makes it super easy to quickly deploy such base configs. Set up your base configuration, and then type something like this:

root@vMX_1> show configuration | save BASE_OSPF_CONFIG.txt
Wrote 179 lines of output to 'BASE_OSPF_CONFIG.txt'

root@vMX_1>

Instead of showing the config on the CLI, Junos will instead write the output of the command to a text file with a name of your choice, saved to your home directory on the box.

You can type “file list” to see all the files currently in your home folder. Long time readers will spot a few base configs below from some of my previous blog posts!

root@vMX_1> file list
/root/:
.cshrc@ -> /packages/mnt/os-runtime/root/.cshrc
.login@ -> /packages/mnt/os-runtime/root/.login
.profile@ -> /packages/mnt/os-runtime/root/.profile
RSVP_FF_LAB1.txt
RSVP_FF_LAB2.txt
RSVP_FF_LAB3.txt
RSVP_FF_LAB4.txt
BASE_CONFIG_AUTO-BANDWIDTH.txt
VPLS_BROADCAST_AND_UNKNOWN_POLICER.txt
VPLS_MAC_Move_Action.txt

Now you can easily load any of them by going into configuration mode, and typing this:

[edit]
root@vMX_1# load override BASE_OSPF_CONFIG.txt
load complete

[edit]
root@vMX_1#

This completely deletes the current config, and replaces it with your new base. Remember that it isn’t saved until you commit it, so you can still make extra changes first, or even change your mind with a rollback!

It’s even better if you’re using a command-line manager app like iTerm2 for MacOS, which lets you type CLI output to multiple windows at once. I like to spin up my ten routers, have ten CLI windows at once (one with a session to each router), hit cmd-shift-i to write to all screens at once, and then type the commands to load my config of choice for today’s labbing. The commands go to all ten routers at once, and my new lab is ready to use. Very clean!

Oh, and deleting the file is just as easy: simply type “file delete BASE_OSPF_CONFIG.txt“.

 

SET CLI SCREEN-WIDTH

A final quick one to round things off.

Imagine you’ve logged onto a box, and started configuring a firewall filter. Ever had this happen?

[edit]
root@LAN_100_HOST_40# ...source-address 192.168.10.0/24

Believe it or not, what you’re looking at there is the very end of a long line of typing, of which most is hidden. That’s because Junos, like a lot of platforms, has a default character limit for what it can display on the CLI, and this default is 80 characters.

Luckily though, this is easily fixed. Notice that this “set” command below is actually done in operational mode, not configuration mode:

root@LAN_100_HOST_40> set cli screen-width 1000
Screen width set to 1000

root@LAN_100_HOST_40>

This will give you a much larger line of text on your screen. The number actually goes up to 1024, but I find it easier to type 1000. In fact, this is the very first command I type when I log onto any box that I know I’m going to do anything significant on. I actually type it on instinct now, without even thinking about it. Which is probably a bit dangerous, but there we are!

Once you’ve typed this, you will now be able to see long commands all at once:

[edit]
root@LAN_100_HOST_40# set firewall family inet filter PROTECT_RE term BLOCK_SSH from source-address 192.168.10.0/24

The only thing that frustrates me about this is that you can’t add this to the actual configuration. When you log off, this setting is lost, and you’ll need to type it again when you log back in. I expect there’s a good reason for it, like compatibility with all command line apps maybe. If you were very clever then you could probably write some kind of event script which deploys it on login or something. Alas though, I am not clever. Perhaps you yourself might look into making such a script, and share it with everyone? Sounds like a fun project to learn some basic coding!

 

THAT’S IT!

Did you know about these already, or were they new to you? Let me know in the comments below! And also, this is only a small slice of what’s available to you. I’ve just chosen my favourites to get you excited, but there’s plenty more where that came from. If ever you study the JNCIA-Junos cert then you’ll learn all of these, and more.

If you enjoyed this post, then I’d love it if you shared it on your favourite social media of choice, or maybe even sent it directly to your colleagues who might find it helpful.

If you’re on Mastodon, follow me to find out when I make new posts. (2024 edit: I’m also on BlueSky nowadays too. I was once on Twitter, but I’ve given up on it, on account of… well, I don’t need to finish that sentence, do I.)

And if you fancy some more learning, take a look through my other posts. I’ve got plenty of cool new networking knowledge for you on this website, especially covering Juniper tech and service provider goodness.

It’s all free for you, although I’ll never say no to a donation. This website is 100% a non-profit endeavour, in fact it costs me money to run. I don’t mind that one bit, but it would be cool if I could break even on the web hosting, and the licenses I buy to bring you this sweet sweet content.

Thank you very much for reading, and see you next time!