Expert Mode

Wednesday, 15 August 2012

GAIA CLISH Basics (Interfaces,Routes,Bonds,Saving)

Here are some really 'basic' GAIA CLISH commands everyone should know

Basic Configuration for an interface via CLISH (ifconfig/ethtool still work within expert-shell in case you prefer those):

Configure the interface with an appropriate ipv4 address and netmask

GAIA1> set interface eth2 ipv4-address 10.100.100.1 mask-length 24

Interace comments

GAIA1> set interface eth2 comments "Internal Interface"

Interface speed hardcoding (use 'auto-negotation on' instead if required)

GAIA1> set interface eth2 link-speed 1000M/full

Turn the interface "on" and active

GAIA1> set interface eth2 state on

Show current information

GAIA1> show interface eth2
link-speed 1000M/full
ipv6-autoconfig Not configured
speed 1000M
mac-addr 00:0c:29:38:9f:6d
state on
duplex full
type ethernet
comments {Internal Interface}
mtu 1500
auto-negotiation Not configured
ipv4-address 10.100.100.1/24
ipv6-address Not Configured

Statistics:
TX bytes:0 packets:0 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:0 packets:0 errors:0 dropped:0 overruns:0 frame:0

Adding static routes in GAIA CLISH:

Destination of 10.100.101/24 via 10.100.100.2

GAIA1> set static-route 10.100.101.0/24 nexthop gateway address 10.100.100.2 on

GAIA1> show route
Codes: C - Connected, S - Static, R - RIP, B - BGP,
       O - OSPF IntraArea (IA - InterArea, E - External, N - NSSA)
       A - Aggregate, K - Kernel Remnant, H - Hidden, P - Suppressed

S     0.0.0.0/0           via 192.168.0.1, eth0, cost 0, age 2413
C     10.100.100.0/24     is directly connected, eth2
S     10.100.101.0/24     via 10.100.100.2, eth2, cost 0, age 37
S     10.100.102.0/24     via 10.100.100.2, eth2, cost 0, age 20
S     10.100.103.0/24     via 10.100.100.2, eth2, cost 0, age 17
S     10.100.104.0/24     via 10.100.100.2, eth2, cost 0, age 14
S     10.100.105.0/24     via 10.100.100.2, eth2, cost 0, age 11
S     10.100.106.0/24     via 10.100.100.2, eth2, cost 0, age 8
S     10.100.107.0/24     via 10.100.100.2, eth2, cost 0, age 5
S     10.100.108.0/24     via 10.100.100.2, eth2, cost 0, age 2
C     127.0.0.0/8         is directly connected, lo
C     192.168.0.0/24      is directly connected, eth0

Creating a bond from CLISH:

#Create the bond and assign a slave interface in one command:

GAIA1> add bonding group 0 interface eth1
Enter an interface to add to the bond group.
Only ethernet interfaces can be added to a bond group.
The interface shouldn't have any IP addresses or aliases configured.
Hit tab to obtain the available interfaces that can be added to the bond group.

# Set the "mode" of the Bond (I choose 8023ad here - aka LACP)

GAIA1> set bonding group 0 mode 8023AD

# Set the bond's primary interface:

GAIA1> set bonding group 0 primary eth1

# View your bond:

GAIA1> show bonding group 0
Bond Configuration
    xmit-hash-policy layer2
    down-delay 200
    primary eth1
    lacp-rate slow
    mode 8023AD
    up-delay 200
    mii-interval 100
    Bond Interfaces
        eth1

# This information is also available via Expert mode via /proc:

[Expert@GAIA1]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 17
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:0c:29:38:9f:63
Aggregator ID: 1

Saving your configuration:

GAIA1> save config

Friday, 6 July 2012

SPLAT/GAIA: How to determine bond status (link/LACP etc)

Hi Everyone,

Had this question asked today: "How do you determine if your LACP (or XOR) bond is up and running and what state is it in?

Since ethtool and ifconfig don't provide you LACP details, you have to check via /proc like so (removed MACs for privacy):

Looking at bond0 here:

cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.2.4 (January 28, 2008)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

802.3ad info
LACP rate: slow
Active Aggregator Info:
        Aggregator ID: 2
        Number of ports: 2
        Actor Key: 17
        Partner Key: 32773
        Partner Mac Address: **************

Slave Interface: eth2
MII Status: up
Link Failure Count: 1
Permanent HW addr: **************
Aggregator ID: 2

Slave Interface: eth3
MII Status: up
Link Failure Count: 0
Permanent HW addr: **************
Aggregator ID: 2

Slave Interface: eth4
MII Status: down
Link Failure Count: 0
Permanent HW addr: **************
Aggregator ID: 3

Slave Interface: eth5
MII Status: down
Link Failure Count: 1
Permanent HW addr: **************
Aggregator ID: 1

You can also configure how Checkpoint monitors the bonds with cphaconf show_bond

The steps found with sk69180 should also be followed to ensure slave interfaces have been added correctly.

Wednesday, 27 June 2012

CheckPoint HA: How to force a failover (ClusterXL/VRRP)

Hi Everyone,

Based on some recent conversations I've had, it seems most people don't know how to force or test a failover with Check Point HA.

There is a single requirement for non-SPLAT/GAIA systems; FW-1 Monitoring State needs to be enabled. If you're running IPSO, you can do this via the VRRP configuration page.

To force a failover, run the following commands on the current cluster master:

This creates a pnote (problem notification) that is in problem state:

cphaprob -d fail -s problem -t 0 register

Verify it's in problem state with

cphaprob stat

and

cphaprob -i list

(you should see 'fail' in problem state)

Once you've finished your testing, run these two to reset it:

cphaprob -d fail -s ok report
cphaprob -d fail unregister

Make sure to verify that the pnote has been removed correctly before you log off.

That's it!

Wednesday, 29 February 2012

Upgrade to R70.50 from R70.30/40 fails due to licensing errors on IPSO

Hi everyone,

It's been awhile since I've posted anything, but tonight I actually experienced something I hadn't seen before, so I figured I should share:

I was in the process of upgrading three separate clusters from R70.30/R70.40 to R70.50 and was presented with this error upon running the UnixInstallScript:

# ./UnixInstallScript

***********************************************************
Welcome to Check Point R70.50 Installation
***********************************************************
In order to install Check Point R70.50 you must first install Check Point R70 Software Blades
For additional information please refer to the release notes.

I checked the licenses and noticed that I was in fact already using Blade Licenses on some clusters, while on one I was still using the old system.

This perplexed me greatly. Upon digging around in /opt I noticed that CPshared was *completely* missing (if anyone knows why this is, please let me know):
# cd /opt
# ls -lah CPshared
ls: CPshared: No such file or directory

Upon realizing that this was the case, I moved to correct the issue (CPshared is just a link to /svn really)
# mkdir CPshared
# cd CPshared
# ln -s /opt/CPsuite-R70/svn 5.0

Once this was complete and I had 5.0 linking to /svn, I tried to run the script once again (with success!):

***********************************************************
Welcome to Check Point R70.50 Installation
***********************************************************
The following components will be installed:
* R70.50
Installation Application is about to stop all Check Point Processes.
Do you wish to continue (y/n) [y] ?

I've seen a few unanswered posts around the community with the same error, so hopefully this will help someone out :)

Cheers,