There could be times that BGP is not being synchronised properly or something. First of all, check up the localnetmask on both routers. I have -seen- issues that the netmasks weren’t the same in the same network which prevented BGP from properly being exchanged. So, hint: Check netmasks / network information and make sure they are correct!
Today I was toying around with Eventia Reporter in order to generate some reports about the things I did with checkpoint etc. Since I build up a new environment from scratch I needed to import various logfiles. When you enter the GUI and start a recording session there ; you will find that you can only do this one log at a time. Which is time consuming and frustrating because the machines have time available to process logfiles instead of having free-cpu cylcles left. I couldnt find any usefull option last night when I tried to do this scriptified; but I found some information on the CPUG.org forum that could help you (original post here ).If you want to do this automatically you should do something like:
log_consolidator -R -e Yes -s ip-addr-of-logserver -x Yes -o No -t Specified_Log -l <logfile>.log -a Begin_of_Log -b <your connections table>
If you script that it would become something like (easy example on splat, use nohup to start the process or you will loose the script eventually due to automatic logouts):
#!/bin/sh
APP=/opt/CPrt-R65/log_consolidator_engine/bin/log_consolidator
LOGDIR=/opt/CPsuite-R65/fw1/log # use the path where your backup logs are stored here
for LOG in `ls $LOGDIR/*<pattern if needed>*.log`
do
$APP -R -e Yes -s <loghost> -x Yes -o No -t Specified_Log -l $LOG -a Begin_of_Log -b <table>
done
Lately I have been attempting to upgrade several Checkpoint Smart Center stations from R60 to R65. Not without a glitch though. So I thought lets write a little bit of documentation about this.
Initially I needed to upgrade the old management station twice to get to R65 which already was a pitfall. But after that it started working properly.Next I downloaded the latest NGX utilties on the internet and performed a backup to prepare for an OS upgrade (changing OS from the company in Redmond to SPLAT).
So far everything went smooth and I felt really relaxed doing it.I rebuild one of the management stations with SPLAT R65 and copied over the huge file (2.5GB in size) which took a little and yeah it was finally there. I wanted to import the file, but sadly I got several errors stating that I could not copy the file etc. I ofcourse am ignorant so I tried to do this manually; and darn that works! Now extracting the file… also works. So why does “upgrade_import” cause problems? After a long struggle, even noticing (I posted forum posts) this on the internet I found the cause of the problem at least the problem for me.
My backups were huge because of database revisions being saved in it as well (as it should) I removed them after a tip from my support company (the tip was for something else but it lead to the solution) and remained with a 53MB file (yeah a bit smaller then before ;-)).
The moment that my support party told me that I could lower the size of the file so that we could analyze it together I got struck by lightning (well an idea struck me) What if the system does not allow files bigger then 2GB (Which is probably hardcoded because the manual copy went OK!) ? So now having the 53MB big backup file, I copied that over much quicker and imported that… it worked..
Symptoms:
DecompressImportedFile: Error >> Failed to copy /var/backups/xxxxx.tgz to /opt/CPsuiteR65/fw1/tmp/upgrade_temp_dirSolution:
Get rid of the database revision files (You can safely back them up and remove the contents of the repository directory and the fwdatabaserevision.dwb file (or something like that)) rerun the backup import on that specific backup and be done with it.
Q: My SSH connection is sometimes slow. It can take up to half a minute to connect to a remote host. What is the problem?
A: The SSH Daemon application uses DNS to do a reverse lookup of the host connecting to it. There can be several issues which make this reverse lookup query unsuccesfull. E.g. There might be a broken DNS on the internet which does not reply, the connection might be overloaded, causing dropped traffic etc.
You can do a couple of things to get rid of this: 1) You can try and add your source host to the /etc/hosts file. This will give sshd the reverse lookup it wants and speedup connection time. 2) You can try and run a local resolver (Which only does ‘recursive’ queries for your host and/or network). Using the “UseDNS no“ flag within OpenSSH will not actually speedup the process! If that all fails, there might be some more trouble then we currently expect. Try running some queries on the resolver defined in /etc/resolv.conf and see whether they get through, is the query answered quickly? etc. Feel free to post a message to a help-mailinglist in case this all does not help.