fbpx

System-Engineering | 4 min read

How the Unix basis from Junos helped me handle a migration efficiently

March 2021
written by Remi Locherer
Senior Network Engineer

Do you sometimes feel slowed down by the limited CLIs of common networking devices? I often miss the powerful Unix shell with all its associated tools when dealing with the common CLIs. An increasing number of systems now include standard Unix tools. Junos includes them for a long time. Read on to learn how I made use of these tools to efficiently migrate a VPN gateway.

Recently, I had the task to do a customer migration from a single SRX 340 to a clustered SRX 340. The SRX was used as a VPN gateway for a couple of site-to-site IPsec connections. With the tools provided by Junos some scripting knowledge, this was an easy task, which I’m going to outline in this article.

The goal was that we do not need to involve the parties managing the other ends of the VPNs. But a minimal downtime was acceptable.

As a first step, two new SRX firewalls were set up with a very basic cluster configuration following the guide from Juniper. Afterwards, the appropriate Junos release was installed. But at this time, no interfaces other than the management and cluster interfaces have been set up.

The next step was to configure the redundancy groups and the associated clustered interfaces (reth) without assigning them an IP address.

On the day before the maintenance window, I copied the config to the new device but did not load it yet. Instead, I switched to the FreeBSD shell (start shell) and edited the copied config file with vi. Config parts like hostname could be deleted since they are already handled by the active minimal config. While still in vi, the old interface names could easily be replaced with their cluster counterparts:

:%s#ge-0/0/3#reth0#gc

This is one of the advantages of Junos: all the Unix tools I’m used to are available on each Junos box – be it a switch, router or firewall.

In the next step, it was very handy to have these powerful tools available. To ensure all the IPsec sessions can be established immediately once the new cluster is active, the sessions first have to be disabled. This lets the gateways on the other side know the old sessions are not valid anymore. And since we deal with more than just a handful of sessions, we don’t want to type everything manually.

To disable a VPN, the following commands are used on SRX devices:

> configure
# deactivate security ike gateway
# deactivate security ipsec vpn
# commit

To do this for all configured VPNs on the old SRX, I used these commands:

> start shell
% cli -c "show configuration security | display set" | awk '/security (ipsec vpn|ike gateway)/ { print "deactivate " $2 " " $3 " " $4 " " $5 }' | uniq > deactivate.set.conf
% cli -c 'configure; load set deactivate.set.conf; commit'

In the first step, all VPNs and Gateways are extracted from the config and the deactivate commands are built. Then, the statements are loaded and committed to actually disable the VPNs.

Once this is done, it makes sense to verify the sessions are actually down.

show security ike security-associations
show security ipsec security-associations

If this was successful and no sessions are up, it is time to disable the interfaces on the old SRX and load the prepared config on the new cluster. Now, we can verify that there is no configured session that is not up on the new cluster.

show security ipsec inactive-tunnels

Should a rollback be required, it is super simple on a device running Junos: just use the built-in rollback function. First on the cluster and then on the old SRX do a rollback 1 and commit.

Without the Unix tools available I would have to do the changes manually in an editor on my computer. This would have taken more time to prepare the migration and the likelihood of introducing errors would be much higher. But since I could use this tooling, the change was quick and error-free.

Related Service See how we help businesses with our network consulting services:
Network Consulting Our network consulting service portfolio covers various topics. See more
March 2021
written by Remi Locherer
Senior Network Engineer

Most Popular

Network-Engineering | 8 min read

Junos upgrade – filesystem is full

Not enough storage during Junos upgrade (EX2300 and EX3400). An extension of Juniper's article…

Read more