SPAN port on a Switch

Here is a quick post on how to configure a SPAN port on some of the various switch gear should you need one





Cisco Catalyst 2850, 2940, 2950, 2955, 2960, 2970, 3550, 3560, 
3560-E, 3750, 3750-E 4500/4000

conf t
monitor session 1 source interface gigabitEthernet 0/17 both
monitor session 1 destination interface gigabitEthernet 0/15
write mem

C6500/6000 Series Switches That 
Run Cisco  IOS System Software, Cisco Nexus Series Switches That Runs  
NX-OS Software

monitor session session_number source interface interface-id [, | -] [both | rx | tx]
monitor session session_number destination interface interface-id

Cisco Catalyst 2900, 4500/4000, 5500/5000, 
  and 6500/6000 Series Switches That Run CatOS

set span source_port destination_port [rx | tx | both]


root@switch# edit
root@switch# set ethernet-switching-options analyzer mirror-3d input egress interface ge-0/0/6.0
root@switch# set ethernet-switching-options analyzer mirror-3d input ingress interface ge-0/0/6.0
root@switch# set ethernet-switching-options analyzer mirror-3d output interface ge-0/0/13.0
root@switch# commit


Monitoring an Individual Trunk Port
By default, when you monitor the primary port in a trunk group, aggregated traffic for all the ports in the trunk group is copied to the mirror port. You can configure the device to monitor individual ports in a trunk group. You can monitor the primary port or a secondary port individually.

To monitor traffic on an individual port in a trunk group, enter commands such as the following:

ServerIron(config)# mirror ethernet 2/1
ServerIron(config)# trunk switch ethernet 4/1 to 4/8
ServerIron(config-trunk-4/1-4/8)# config-trunk-ind
ServerIron(config-trunk-4/1-4/8)# monitor ethe-port-monitored 4/5 ethernet 2/1 in

Palo Alto Networks boxes spray firewall creds across the net

This was the title of a security blog from a year ago at

The site goes on to state “The mess is a result of a user control module being allowed to operate in untrusted zones, rather than a vulnerability in Palo’s kit.”

The full article is at and they quote HD Moore who says “This flaw can “expose organizations to remote compromise, noting that attackers could use off-the-shelf tools to bounce authentication to external customer NTLMSSP infrastructure such as SSL VPNs, Outlook Web Access, and Microsoft IIS web servers”

“Palo Alto Networks’ response is an advisory pointing users to best practice guidelines to harden their kit.”

You can read the article here at :

My two cents : Interesting that their default isn’t hardened to begin with…just saying.


No Downtime Check Point Cluster Upgrades

Ever wonder how to do a no downtime upgrade on a Check Point Cluster?

Many of my customers have asked me for best practices for upgrading their clusters. I have shown the methods (and done them) throughout the years of failover back and forth between members using state to effectively create a no downtime scenario, however there was no real guarantee of uptime or that a connection wouldn’t be dropped.

Well now in R77 you can do what is called a full connectivity upgrade. Basically it means:

• Connection failover is guaranteed.
• There is always at least one active cluster member that handles the traffic.
• Connections are synchronized between cluster members running different Check Point software versions.

Sound good ???

Here are none simple steps on how you do it:

Before you upgrade:
• Make sure that the cluster has 2 members, where one of them is the Active member and the other member is in Standby.
• Get the sync interface IP address and the cluster member ID of the Active cluster member.

From the command line in Expert type: cphaprob stat

To upgrade the cluster:

  1. In SmartDashboard:
    – In the Gateway Cluster General Properties window, change the Cluster version to the upgraded one.
    – In the Install Policy window, go to the Installation Mode area > Install on each selected gateway independently and clear For Gateway Clusters install on all the members, if it fails do not install at all.
  2. Install the security policy on the cluster.
    (Note – The policy successfully installs on the Ready cluster member and fails to install on the Active cluster member. This is expected, ignore the warning.)
  3. On the Active cluster member, run: cphaprob stat
    (Make sure the state is Active or Active Attention, and record the Sync IP and the Member ID of the cluster member.)
  4. On the upgraded cluster member, run these commands:
    cphaprob stat
    (Make sure that the cluster member is in Ready state.)
    cphacu start
    (The Connectivity Upgrade runs. When it finishes, the member’s state is Ready for Failover.)
    cphacu stat
    (Make sure that the Active cluster member handles the traffic.)
  5. On the Active cluster member, run these commands:
    cphaprob stat
    (Make sure the local member is in Active or Active Attention state, and the upgraded member is in Down state.)
    (The connections fail over to the upgraded cluster member.)
  6. On the upgraded cluster member, run: cphaprob stat
    (Make sure that it is now in the Active state.)
  7. On the new upgraded cluster member, run: cphacu stat
    (Make sure it handles the traffic.)
  8. Upgrade the former Active cluster member.
    (Make sure to reboot it after the upgrade.)
  9. Install Policy.

Note: After the cluster upgrade is complete, the Cluster Control Protocol works in broadcast mode.  I recommend this mode however if you were running in multicast mode and wish to return to that state then on all cluster members run the command: cphaconf set_ccp multicast

That is all it takes to have a successful full connectivity upgrade of an HA cluster. If however you have more than a two member cluster or have a VSX cluster or would like more information check out the CP_CU_BestPractices.pdf guide on how to do all this.


References :

Connectivity Upgrades Best Practices R77 (CP_CU_BestPractices.pdf)


Backing up your Check Point Infrastructure

I have had many a customer ask me “…how should I backup my Check Point?”

There have actually been many posts in the usercenter about this showing how and recommended ways. However I decided to consolidate some of that and put them here in this post so that you can read it. I am also including the specific articles used that you can reference.

Bottom line if you are backing up your stuff that is good news, however if you are not then you need to be doing so!!

Here are two separate scenarios on how to backup and restore your Check Point Infrastructure you can use. I will also include a supplemental backup that you can do for your management station as well (see Management Supplement #1)


The snapshot creates a binary image of the entire root disk partition. This includes Check Point products, configuration, and operating system. It is important to note that this does not include the log files as logs are not stored in the root partition. There are still space requirements you should consider before doing scenario #1.

To create the snapshot image requires free space on the Backup partition. The required free disk space is the actual size of the root partition, multiplied by 1.15.

 The free space required in the export file storage location is the size of the snapshot multiplied by two.

 The minimum size of a snapshot is 2.5G, so the minimum free space you need in the export file storage location is 5G.

To create a snapshot image:

It is important to note you can do this from the command line or the web portal (WebUI) (see GAIA Administration Guide for the command line), so just from a web browser login to the GAIA portal.

1. In the tree view, click Maintenance > Image Management.

2. Below available images, click New Image. The Create New Image window opens.

3. In the Name field, enter a name for the image.

4. Optional: In the Description field, enter a description for the image.

5. Click OK.

You can choose to leave it on the filesystem, &/or you can save it off.  However, if you save it off as well as leave the latest and greatest on the filesystem you will have access to it in a pinch.



How to Restore an image you took but don’t have it on the filesystem:

Now that you have your image on the filesystem (or it was already there) here is how to restore it.

1. In the tree view, click Maintenance > Image Management.

2. Select an image.

3. Click Revert. The Revert window opens.

Of course this procedure means the device is in a down state at the time, however if you are having to revert to an image you created I am guessing that is the least of your worries at that moment. But worry not!  Restore it and you will be up and running with the system looking like it was when you took the snapshot.


System Backup can be used to backup current system configuration. A backup creates a compressed file that contains the Check Point configuration including the networking and operating system parameters, such as routing and interface configuration etc., but unlike a snapshot, it does not include the operating system, product binaries, and hotfixes.

You can store backups locally, or remotely to a TFTP, SCP or FTP server. You can run the backup manually, or do a scheduled backup

To add a manual one time backup:

1. In the tree view, click Maintenance > System Backup

2. Click Add Backup.

The New Backup window opens.

3. Select the location of the backup file:

This appliance

TFTP server. Specify the IP address.

SCP server. Specify the IP address, user name and password.

FTP server. Specify the IP address, user name and password.

To add a scheduled backup:

1. In the tree view, click Maintenance > System Backup.

2. Click Add Scheduled Backup. The New Scheduled Backup window opens.

3. In Backup Name, enter the name of the job. Use alphanumeric characters only, and no spaces.

4. In Backup Type, enter the location of the backup file.

    This appliance

    TFTP server. Specify the IP address.

    SCP server. Specify the IP address, user name and password.

    FTP server. Specify the IP address, user name and password.

5. In Backup Schedule, select the frequency (Daily, Weekly, Monthly) for this backup. Where relevant, enter the Time of day for the job, in the 24 hour clock format.

6. Click Add. The scheduled backup shows in the Scheduled Backups table.


To restore from a backup:

1. In the tree view, click Maintenance > System Backup.

2. Select the backup file and click Restore Backup.



To do a migrate export for your management station (SmartCenter) from the command line.

This migrate export captures your management station’s database (policies, objects, certs etc…) however it is Not capturing any O/S related info such as the IP, hostname, routing etc…

1. Log in to the expert mode.

2. Type: cd $FWDIR/bin/upgrade_tools

3. Type: ./migrate export <exported database name>.tgz

4. Do the instructions shown on the screen. This creates the <exported database name>.tgz file.

5. Copy the file off and save it.

That is all folks. Not that hard to do, and once you are setup you won’t need to worry should anything ever happen.  I recommend you do all of the scenario’s I mentioned on a regular basis (just like any server backup) then you can truly be successful.

You can read more information about what I wrote here at our usercenter.



Gaia Administration Guide R77

Gaia R77 Installation and Upgrade Guide