This is the second post in the Loading Configs series. In this post, we will cover the load patch command. The beauty of the load patch command is that you can load the config on one device, issue a show | compare, and take that output and patch another device. This is also useful when you want to test your commands for a change, roll it back, and then re-apply it later.
Here is a quick refresher on what we are doing…
For this lab series, we will use a simple topology to demonstrate the different ways to load configs. We have our SRX configured with TRUST and UNTRUST zones, a connection to the Internet, and a Windows 7 PC that has a browser installed. We will focus on making changes to our security policies.
Our current configured security policy is fairly straight forward. NAT, routing, security zones have all been pre-configured for this post. We will be permitting traffic from TRUST to the Internet for HTTP, ICMP, and DNS initially with the goal to add an HTTPS policy and have traffic pass. Our currently configured security policy is below:
security {
policies {
from-zone TRUST to-zone UNTRUST {
policy PERMIT-HTTPS {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit;
}
}
policy PERMIT-ICMP {
match {
source-address any;
destination-address any;
application junos-icmp-all;
}
then {
permit;
}
}
policy PERMIT-DNS {
match {
source-address any;
destination-address any;
application [ junos-dns-tcp junos-dns-udp ];
}
then {
permit;
}
}
policy DENY-ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
reject;
}
}
}
}
}
You can see the remainder of the setup on our first post here.
So the next command that we are talking about is load patch. This command is used when you want to deploy the same configuration to many devices, or more commonly if you want to save a configuration for later deployment during a change window.
So say we wanted to roll out the HTTPS change during a change window and test our commands on a lab device. For this example, we will load our config, insert it where we need, and then perform a commit check. We will use what we learned in our last post by starting with load merge.
[edit]
jfry@FRYGUY-LAB# load merge terminal
[Type ^D at a new line to end input]
security {
policies {
from-zone TRUST to-zone UNTRUST {
policy PERMIT-HTTPS {
match {
source-address any;
destination-address any;
application junos-https;
}
then {
permit;
}
}
}
}
}
load complete
[edit]
jfry@FRYGUY-LAB# insert security policy from-zone TRUST to-zone UNTRUST polciy PERMIT-HTTPS before policy DENY-ALL
[edit]
jfry@FRYGUY-LAB# show | compare
[edit security policies from-zone TRUST to-zone UNTRUST]
policy PERMIT-DNS { ... }
+ policy PERMIT-HTTPS {
+ match {
+ source-address any;
+ destination-address any;
+ application junos-https;
+ }
+ then {
+ permit;
+ }
+ }
policy DENY-ALL { ... }
[edit]
jfry@FRYGUY-LAB# commit check
configuration check succeeds
Here is a quick video of the commands.
The key parts of the outputs are the commit check and show | compare. The commit check allowed us to verify that the commands we are using are correct and the show | compare displayed the changes in the right order in the configuration. Now, what can we do with that? Well – that is where the load patch comes into play.
If we look at the output of the show | compare, we can see what is being added by the plus sign (+), the location, and the order in the configuration it is being added.
[edit security policies from-zone TRUST to-zone UNTRUST]
policy PERMIT-DNS { ... }
+ policy PERMIT-HTTPS {
+ match {
+ source-address any;
+ destination-address any;
+ application junos-https;
+ }
+ then {
+ permit;
+ }
+ }
policy DENY-ALL { ... }So let’s issue the load patch command and paste in the output above. We need it all, the [edit security policies….] all the way to [policy DENY-ALL], and see what happens with the security policy order.
[edit]
jfry@FRYGUY-LAB# load patch terminal
[Type ^D at a new line to end input]
[edit security policies from-zone TRUST to-zone UNTRUST]
policy PERMIT-DNS { ... }
+ policy PERMIT-HTTPS {
+ match {
+ source-address any;
+ destination-address any;
+ application junos-https;
+ }
+ then {
+ permit;
+ }
+ }
policy DENY-ALL { ... }
load completeNow let’s look at the security policies. As you can see from the output below, the PERMIT-HTTPS has been placed before the DENY-ALL policy. We did not need to move it or anything, the patch command showed Junos where we wanted it.
[edit]
jfry@FRYGUY-LAB# show security policies | no-more
from-zone TRUST to-zone UNTRUST {
policy PERMIT-HTTP {
match {
source-address any;
destination-address any;
application junos-http;
}
then {
permit;
}
}
policy PERMIT-ICMP {
match {
source-address any;
destination-address any;
application junos-icmp-all;
}
then {
permit;
}
}
policy PERMIT-DNS {
match {
source-address any;
destination-address any;
application [ junos-dns-tcp junos-dns-udp ];
}
then {
permit;
}
}
policy PERMIT-HTTPS {
match {
source-address any;
destination-address any;
application junos-https;
}
then {
permit;
}
}
policy DENY-ALL {
match {
source-address any;
destination-address any;
application any;
}
then {
reject;
}
}
}Below is a quick video of me issuing those commands we just demonstrated.
As you can see, it inserted them in the proper location just based on the information we loaded. This is a great command if you need to deploy the same configuration to many devices or have verified it in a lab and want to deploy it to production. I use the command on a regular basis when making changes where the order of operation is important.