Copying static routes from R55 to R62

[nolan.rumble]

Hi,

I'm in the process of upgrading a R55 SPLAT box to R62. Now all of the routes on the firewall are static routes. Is there a way to copy over a file which contains all the static routes?

From what I gathered, the routes on the R55 box are stored in /etc/sysconfig/cpnetstart file and on the R62 box, the routes are stored in /etc/sysconfig/netconf.C.

Now the formats of these files are definitely different.

If there were only a couple of routes, it wouldn't be a problem to type them out again, however some of the firewalls which we will be upgrading have in excess of 100 static routes which can become a nightmare to type in again.

Is there a way to convert the one file to the other or is there another way to go about doing this?

Thanks
Nolan

[dsb.nepo]

you can go this way:

at the source system in expert mode do:

netstat -rn | grep ^[0-9] | awk '{printf "route add -net %-15s gw %-15s netmask %s\n", $1, $2, $3}' | sort > R55_routing_table

the output is someting like this:

route add -net 10.1.1.0        gw 10.0.0.2      netmask 255.255.255.0
route add -net 10.1.2.0        gw 10.0.0.2      netmask 255.255.255.0

transfer this file to a machine with a good editor and review your routes, edit or delete routes.

transfer the file to the new gateway and in expert mode:

sh ./R55_routing_table_reviewed

then do an route -save and it is done

[dsb.nepo]

sorry, the command is

route --save

and not route -save

if you would like to have the interfaces documented in the dump change the command to this:

file: dump_routes_to_restore_file.sh

#!/bin/sh
netstat -rn \
        | grep ^[0-9] \
        | awk '{printf "route add -net %-15s gw %-15s netmask %-18s # %s\n", $1, $2, $3, $8}' \
        | sort -n -k6,6

[nolan.rumble]

Great!! Works like a charm! :)

Thanks very much for your help.

Regards,
Nolan

[cormic]

Excellent tip. It also works between R55 and R65 as well :)

Thanks for the help

[napalm255]

This is a great script that worked like a champ for me. We're upgrading from R55 to R65 and I just used this script to backup the routes in our live environment and import them into our test lab. Again, worked great!

Thanks for the script. I was going to create by own bash script when I found this one and it saved me some time!!

P.S. This is my first time to this site and I feel like I've been missing out already as I've supported a checkpoint cluster for a few years now.

[napalm255]

We asked Checkpoint TAC how to backup and restore routes and this is there answer:

There really no documented automate way to copy the routes from R55 over to NGX R65 installed on new hardware.

But if this was an in place upgrade you would already have your routes, so try this make a backup copy of the cpnetstart file from the R55 firewall. Install R55 on the new hardware then replace the cpnetstart file on the newly installed R55 firewall before rebooting the firewall.

Now you should be able to do an in place upgrade on the new hardware to R65, this should retain your routing information. The routing information is store in the netconf.C file on NGX R65.

This is what our Checkpoint Rep told us after we forwarded him the response from TAC:

Much of the network configuration is contained within the "netconf.C" file
on SPLAT. I do not, however, recommend you copy this file directly from one
enforcement point to another -- there would be too much incorrect
information carried over. What I've done in the past in order to accomplish
the same task is as follows:

1) dump a copy of the routes to a text file via "netstat -rn >
{filename}"
2) Open the output in excel, and massage it, retaining only the IP
network, mask, and gateway.
3) I would then insert text as follows: /bin/save_route add -net
{$$ip$$} netmask {$$mask$$} gw {$$gateway$$}
4) Copy out to a text editor, remove tabs, then execute on the new
gateway.

I'm including a sample Excel spreadsheet with the necessary information.

I've considered scripting this, but have not yet had enough demand. More
often than not, we see snapshots as more essential -- taking a "picture" of
the enforcement point, so that it can be restored.

And the unofficial script here at CPUG is the best option!!!

I just thought I'd share the Checkpoint responses with everyone. I've never been to thrilled with Checkpoint's support.