In Introduction to Junos – Part 1, we reviewed the basics of Junos configuration with advanced features such as groups and apply paths. This section will focus on some additional configuration features that are designed to make your life easier.

Deactivate

It’s a common task to simply disable a feature or routing protocol during a change window. Traditionally, we just delete the configuration in question and go on our merry way. But what if we’re troubleshooting an issue, and we simply want to disable a routing protocol temporarily? No problem – just open notepad, cut and paste the configuration and save it for later. I hope your laptop doesn’t crash while you’re troubleshooting and lose the configuration. Oh, but I’m always prepared, I saved the configuration snippet. My Documents folder has hundreds of such snippets!

What a waste of time; there has to be another option. Junos supports the notion of activation and deactivation. By default, everything in the configuration is activated. If you want to deactivate OSPF for a while, simply use the deactivate command:

[edit] 
root@R1# deactivate protocols ospf

[edit]
root@R1# show protocols ospf 
##
## inactive: protocols ospf
##
area 0.0.0.0 {
    interface fe-0/0/0.0;
    interface fe-0/0/1.0;
}

Now the routing protocol OSPF has been disabled. To activate the configuration and enable OSPF, simply use the activate command:

[edit]
root@R1# activate protocols ospf

With the activate and deactivate commands, there’s no need to use silly tricks like cutting and pasting configuration snippets and saving them for later. Keep in mind that activate and deactivate can be used with any portion of the configuration. You can be very precise and deactivate a single interface, or use a sledge hammer and deactivate all the protocols with one fell swoop.

Protect

There are probably parts of the configuration that are deemed critical and shouldn’t be touched but only a few times a year. A good example that comes to mind is the routing protocols in a core network. It may make sense to create a commit script to double-check that nothing has been modified, but there’s actually an easier method using the protect command.

root@R1# protect protocols ospf

Now the entire [protocols ospf] context is protected against any changes in the future. Let’s try to add another area to OSPF:

[edit]
root@R1# set protocols ospf area 1 interface vlan.100 
warning: [protocols ospf] is protected, 'protocols ospf area 1' cannot \
be created

Nice. This will prevent any network engineers from accidentally making a change to the OSPF configuration. In order to make changes, you must first unprotect the configuration:

[edit]
root@R1# unprotect protocols ospf

Now it’s possible to make changes:

[edit]
root@R1# set protocols ospf area 1 interface vlan.100

Replace

Sometimes mistakes happen. Perhaps your friend said that the DNS server IP was 192.168.1.1. So you go ahead and make a couple of firewall filters using this source address. You commit the change and notice things do not work. You ask your friend to verify the IP address of the DNS server. Whoops – he misspoke and the IP address is really 192.168.100.1. What a pain; now you have to go back, remove the offending IP address, and then add the correct one. This is a perfect situation to use the Junos replace feature.

The replace command is very simple to use. You have to tell it what pattern to match and what to replace it with. In our case we need to find the incorrect IP address 192.168.1.1 and replace it with 192.168.100.1.

[edit]
root@R1# replace pattern 192.168.1.1 with 192.168.100.1

I always feel a bit paranoid using such a big hammer, because you never know what else you might hit by accident. It’s always good to verify what was changed with show compare:

[edit]
root@R1# show | compare 
[edit system services dhcp router]
+    192.168.100.1;
-    192.168.1.1;
[edit interfaces fe-0/0/7 unit 0 family inet]
+    address 192.168.100.1/24;
-    address 192.168.1.1/24;
[edit interfaces vlan unit 0 family inet]
+    address 192.168.100.1/24;
-    address 192.168.1.1/24;
[edit protocols bgp group TRANSIT]
+    neighbor 192.168.100.1;
     neighbor 192.168.1.2 { ... }
[edit protocols bgp group TRANSIT]
-    neighbor 192.168.1.1;
[edit firewall family inet filter REALLY-LONG-AND-GOOFY-FILTER-NAME \
term 1 from source-address]
+    192.168.100.1/32;
-    192.168.1.1/32;
[edit firewall family inet filter JUST-ANOTHER-LONG-AND-ANNOYING-NAME \
term 1 from source-address]
+    192.168.100.1/32;
-    192.168.1.1/32;

Whoa! That command matched way too much stuff and modified sections of the configuration that I didn’t intend. Now I have two problems: 1) now I have to fix the unintended modifications of the replace command and 2) I still have to change 192.168.1.1 to 192.168.100.1. No big deal. Recall our friend the rollback command; let’s copy the running configuration to the candidate configuration:

[edit]
root@R1# rollback 
load complete

Now we’re back at square one. To make the replace command less greedy and only match the firewall filters, let’s change the configuration context with the edit command:

[edit]
root@R1# edit firewall family inet

[edit firewall family inet]
root@R1# replace pattern 192.168.1.1 with 192.168.100.1

That should do the trick. Let’s verify again with show compare:

[edit firewall family inet]
root@R1# top show | compare 
[edit firewall family inet filter REALLY-LONG-AND-GOOFY-FILTER-NAME \
term 1 from source-address]
+        192.168.100.1/32;
-        192.168.1.1/32;
[edit firewall family inet filter JUST-ANOTHER-LONG-AND-ANNOYING-NAME \
term 1 from source-address]
+        192.168.100.1/32;
-        192.168.1.1/32;

Perfect! Now the configuration has been restored and only the firewall filters have been modified after changing the configuration scope with the edit command.

Wildcards

The wildcard command can be used in various ways to match an existing configuration then apply a set of commands. For example if you want change the port-mode of interfaces fe-0/0/4 through fe-0/0/6:

[edit]
root@R1# wildcard range set interfaces fe-0/0/[4-6] unit 0 family \
ethernet-switching port-mode trunk  

Now let’s take a look at the results with show compare:

[edit]
root@R1# show | compare 
[edit interfaces fe-0/0/4 unit 0 family ethernet-switching]
+      port-mode trunk;
[edit interfaces fe-0/0/5 unit 0 family ethernet-switching]
+      port-mode trunk;
[edit interfaces fe-0/0/6 unit 0 family ethernet-switching]
+      port-mode trunk;

The same can be done for deleting configuration as well. To remove all interfaces in [protocols ospf area 0.0.0.0] matching “fe-*” use the wildcard delete command:

[edit] 
root@R1# wildcard delete protocols ospf area 0.0.0.0 interface fe-* 
  matched: fe-0/0/0.0
  matched: fe-0/0/1.0
  matched: fe-0/0/2.0
  matched: fe-0/0/3.0
Delete 4 objects? [yes,no] (no) yes

No need for a show compare when deleting because the wildcard command will automatically display any matches and prompt you to confirm the deletion.

Time-Based Groups

Sometimes you may want to enable certain services during a change control, but disable the service otherwise. A cool trick when using apply groups is to use the when option. You can specify a date or time range as the condition. Once the group is applied to the configuration it will only become active if it meets the when conditions. Let’s suppose we want to enable the root login for SSH between 2am and 3am:

[edit]
root@R1# show groups 
MAINTENANCE-SSH-ROOT {
    when {
        time 2am to 3am;
    }
    system {
        services {
            ssh {
                root-login allow;
            }
        } 
    }
}

The configuration possibilities with time-based groups is only limited by your imagination. Perhaps you want to automatically disable PoE ports on your switch between 10pm and 6am. Another possibility is to inject a static route to the Internet during certain times.

Moving Configuration Chunks

It’s pretty common to move configuration chunks between routers. Junos gives you many different options to do this. You can cut and paste into the terminal, use SSH to copy between devices, or even create patches.

Save

To save a configuration to a file simply use the save command:

[edit]
root@R1# save R1.txt 
Wrote 199 lines of configuration to 'R1.txt'

Now this configuration can be saved for later or copied to another router.

Load

To load a configuration into the candidate configuration, Junos gives you the load command. There are several different options to the load command. The most common are merge and override. The merge option will keep the current candidate configuration and merge in the changes from the specified file. The override option will simply delete the candidate configuration and replace it line for line of the specified file.

[edit]
root@R1# load override R1.txt 
load complete

Now let’s assume we’ve just configured OSPF on router R1 and want to copy the same OSPF configuration to R2.  The first method is to copy and paste set commands:

[edit]
root@R1# show protocols ospf | display set 
set protocols ospf area 0.0.0.0 apply-groups bfd-ospf-area-0.0.0.0
set protocols ospf area 0.0.0.0 interface fe-0/0/1.0
set protocols ospf area 0.0.0.0 interface fe-0/0/2.0
set protocols ospf area 0.0.0.0 interface fe-0/0/3.0

This method tends to work well for most people. You can now simply copy and paste the set commands into another router. However, this doesn’t scale well if you have to apply the OSPF configuration to a large set of routers. The other method scales better because it requires a single command. The first step is to create a patch file:

[edit]
root@R1# show | compare 
[edit protocols]
+   ospf {
+       area 0.0.0.0 {
+           interface fe-0/0/1.0;
+           interface fe-0/0/2.0;
+           interface fe-0/0/3.0;
+       }
+ }

[edit]
root@R1# show | compare | save OSPF-PATCH.txt 
Wrote 8 lines of output to 'OSPF-PATCH.txt'

We use the show compare command to verify that the changes were only related to OSPF. Now we can save this output to a file called OSPF-PATCH.txt and copy it to all the routers that require the change. Once it’s been copied to the router, use the load patch command:

[edit]
root@R2# load patch OSPF-PATCH.txt 
load complete

Now we can verify that the patch file was loaded correctly and see what exactly was changed:

[edit]
root@R2# show | compare 
[edit protocols]
+   ospf {
+       area 0.0.0.0 {
+           interface fe-0/0/1.0;
+           interface fe-0/0/2.0;
+           interface fe-0/0/3.0;
+       }
+ }

Just like a charm. The OSPF-PATCH.txt only contained the changes to [protocols ospf] and was successfully merged into the candidate configuration on R2.

Conclusion

Junos does a great job of getting out of your way and letting you get to work. There is always more than one way to solve a problem; some methods are geared towards a quick fix, while other methods are designed more for solving a problem at scale.

In the words of Richard Feynman, “I gotta stop somewhere. I’ll leave you something to imagine.”