Checkpoint Cluster Control Protocol (CCP)

O Cluster Control Protocol (CCP) é um protocolo proprietário da Check Point utilizado na estrutura de CPHA (Checkpoint Point High Availability ). O protocolo faz uso da port 8116 UDP para comunicação interna entre os membros do cluster.

Existem dois modos do protocolo operar, por default no Gaia R77.30 o CCP trabalha em modo multicast por ser mais eficiente, porém requer uma estrutura que o suporte sendo necessário ter habilitado o IGMP Snooping nos switches por onde passam o tráfego.

Switching to broadcast mode:
# cphaconf set_ccp broadcast

Switching to multicast mode:
# cphaconf set_ccp multicast

Está alteração não requer o cpstop/cpstart ou reboot. Em algumas versões se faz necessário editar o arquivo ha_boot.conf para sobreviver ao reboot.

Diretório $FWDIR/boot/ha_boot.conf

ccp_mode multicast

OU

ccp_mode broadcast

Para validar a alteração, execute o comando:

[Expert@CP]# cphaprob -a if

Required interfaces: 4
Required secured interfaces: 1

eth0 UP non sync(non secured), multicast
eth1 UP sync(secured), multicast
eth2 UP non sync(non secured), multicast
eth3 UP non sync(non secured), multicast

Dependendo da estrutura do ambiente podem existir casos em que um Gateway exista uma interface física ou VLAN a mais que o outro membro do Cluster, se tornando o Ativo do Cluster, pelo protocolo entender que é o gateway mais completo.

Para não haver esse tipo de interpretação é recomendável no Cluster que possuir esta interface a mais, a remoção da monitoração do protocolo CCP, assim quando executado o “cphaprob -a if” não mostrará divergência no estado do Cluster.

No Gateway Standby executar os passos:

cphastop
clusterXL_admin down

Setar a interface a ser removido no arquivo $FWDIR/conf/discntd.if.

eth2

OU

eth2.100

cphastart
clusterXL_admin up

No Gateway Ativo executar os passos:

cphastop
clusterXL_admin down

Setar a interface a ser removido no arquivo $FWDIR/conf/discntd.if.

eth2

OU

eth2.100

cphastart
clusterXL_admin up

Validar que a interface foi removido da monitoração do protocolo:

[Expert@CP]# cphaprob -a if

Um outro cenário que para min foi até um Case em uma das empresas que trabalhei é a forma que o protocolo se comunica com o outro membro.

Neste Case o firewall possuía em torno de 50 VLANs em uma interface física, onde chegavam todos os parceiros, a menor VLAN ID deste ambiente não passava no trunk entre os switches acima do firewall. Ocorria de eventualmente perdermos toda a conectividade dos endereços virtuais que estava nesta interfaces com o Cluster.

Estudando melhor o protocolo descobrimos que ao executar a monitoração do CCP, o protocolo utiliza a menor VLAN ID para fazer o check com o outro membro, no Splat é utilizado uma única VLAN, no Gaia por padrão são duas VLANs. Neste Case esta menor VLAN ID era o ambiente do parceiro, o pacote passava pelo ambiente dele para voltar.

Para sanar este problema no ambiente, seguimos com a alteração da monitoração, fazendo com que o Gaia utilizasse apenas uma única VLAN e especificando o ID a ser usada.

Seguindo os passos:

Setando uma unica VLAN.

$FWDIR/boot/modules/fwkern.conf

fwha_monitor_specific_vlan=1

Especificando a interface ou VLAN interface. Exemplo monitorando a interface Eth1 ou a VLAN 10 da interface Eth3.

$FWDIR/conf/cpha_specific_vlan_data.conf

eth3 10
eth1

Após alterações reiniciar os serviços e aplicar o reboot.

cpstop
cpstart
reboot

Validar a alteração com os comandos:

[Expert@CP]# cphaprob -a if

tcpdump -nni eth1 port 8116

Links uteis:
sk20576
sk57100
sk92784
sk31085

Tags: