ClusterXL sur IPSO et IGMP snooping

décembre 30, 2013  |   Blog   |     |   0 commentaire

Presentation de ClusterXL et CCP

 

Check Point utilise un protocole proprietaire – CCP (Cluster Control Protocol) – pour la communication entre les membres d’un ClusterXL. Ce protocole fonctionne en UDP sur le port 8116 en multicast (mode par défaut) ou bien en broadcast et permet notamment la vérification du status des membres du cluster ainsi que les échanges d’information pour la synchronisation de la table de connexions

Les firewall Check Point étant « statefull », la synchronisation de la table de connexion permet par exemple lors d’une bascule que le firewall accepte les connexions qui étaient déjà ouvertes, ou bien encore d’effectuer du partage de charge entre deux firewall.

La bande passante requise pour le trafic CPP peut donc ne pas être négligeable en fonction du nombre de sessions par secondes qui traversent le firewall.

Prenons par exemple le cas de figure suivant, avec un cluster de Firewall Check Point sur IPSO reliés par l’intermédiaire de deux switches différents.

igmp

 

Etant donné que CCP fonctionne par défaut en mode multicast, nous allons utiliser l’IGMP snooping sur nos switches afin de limiter l’impact de ce trafic sur notre infrastructure.

L’IGMP snooping est une fonctionnalité sur les switches qui permet de en relayer le trafic multicast uniquement sur les ports derrière lesquels se trouvent des hosts s’étant abonné à ce groupe multicast.

Pour cela le switch écoute (i.e. « snoope ») les rapports d’adhésion IGMP afin de déterminer quels sont ses ports qui font partie du groupe multicast

La précision de l’OS utilisé (ici un IPSO) n’est pas anodine. En effet la partie clustering n’est pas gérée uniquement par la couche Check Point, mais également par l’OS lui même. Il peut  donc avoir des différences de comportements avec SPLAT/GAIA

Mise en pratique

La mise en pratique n’est pas forcément aussi simple qu’il y parait.

Tout d’abord, si les Firewalls Check Point fonctionnent par défaut en multicast, la documentation sur la prise en charge d’IGMP (l’envoie de rapports d’adhésion au groupe multicast) est assez floue

Voici le contenu du sk33221 sur ce point :
« When IGMP Snooping is enabled on the switch, it checks the Destination MAC Address of the frames in order to match the frames to IGMP Subscription Group. Since, by default, IGMP membership on cluster members is disabled, they never subscribe to IGMP Group on the switch. As a result, the switch cannot match the CCP packets that are sent to the Multicast MAC address to any IGMP Group and the switch drops these CCP packets. As a result, cluster members do not send or receive CCP packets properly. This triggers the cluster mechanism to assume that cluster members are failing and to declare interfaces as Down and/or to initiate a fail-over. »
et les solutions proposées par Check Point :
  • Disabling IGMP Membership on switches – refer to switch vendor’s documentation.
  • Enabling IGMP Membership on cluster members – refer to sk31934 (ClusterXL IGMP Membership).
  • Setting CCP mode to broadcast – refer to sk20576 (How to set ClusterXL Control Protocol (CCP) in Broadcast / Multicast mode in ClusterXL)

Note: This will allows ClusterXL HA and ClusterXL Load Sharing Unicast to work with IGMP Snooping-enabled switches. However, it will not allow ClusterXL Load Sharing Multicast to work with IGMP Snooping-enabled switches.

La première et la dernière solution, sont équivalente en terme de fonctionnement puisque sans IGMP snooping sur les switches, le trafic sera diffusé sur tous les ports comme du broadcast, et donc génèrera du trafic inutile sur les lien d’uplink par exemple

Nous allons donc nous intéresser uniquement à la mise en place de l’IGMP sur les IPSO

Malheureusement le sk31934 nous renvoie vers un document qui date de 2006 ! Autant dire qu’il n’est pas tellement adapté pour une version récente de Check Point.

Voilà donc ce qu’il faut savoir sur le mode multicast

Tout d’abord, l’IGMP est supporté sur toute les version depuis :

  •    Check Point R60 HFA_04
  •    Check Point R65 GA

Si vous avez une version trop vieille pour IGMP en production, il est surement temps de mettre à jour …

Les membres d’un cluster utilisent une adresse MAC source qui a la forme suivante :

00:00:00:00:FWHA_MAC_MAGIC-kernel-parameter:Member_ID

Le cinquième octet, que l’on appelle « magic number » est par défaut 0xFE. Si vous avez plusieurs clusters sur un même segment (i.e. un même VLAN), il faut alors modifier ce paramètre pour éviter les conflits. La base de connaisance Check Point explique comment faire cela

Commençons par vérifier que le firewall est effectivement en mode multicast :

[Expert@FW1]# 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

Si l’on veut changer du mode broadcast au mode multicast :

[Expert@FW1]# cphaconf set_ccp multicast/broadcast

On vérifie maintenant que l’IGMP est pris en compte à l’aide des deux commandes suivantes :

[Expert@FW1]# cphaprob state
[Expert@FW1]# cphaprob igmp

Si ce n’est pas le cas, il faut :

1/ activer l’agent IGMP sur le firewall en passant la variable fwha_enable_igmp_snooping à 1 :

fw ctl set int fwha_enable_igmp_snooping 1

2/ s’assurer que la modification soit persistente au reboot, pour cela :

modzap _fwha_enable_igmp_snooping $FWDIR/boot/modules/fwmod.o 1

Malheureusement, tout ça ne suffit pas.

On constate que nos firewall s’abonnent bien dans le groupe au moment ou l’interface de synchronisation est activée :

switch# sh ip igmp snooping groups vlan 183
Type: S - Static, D - Dynamic, R - Router port, F - Fabricpath core port
Vlan  Group Address      Ver  Type  Port list
183   */*                -    R     Po1 Po3
183   224.1.2.3         v2   D     Eth101/1/16 Eth100/1/16

Mais quelques secondes plus tard le switch retire les interfaces de nos firewalls du groupe IGMP.

Il en resulte que les datagrames CCP ne sont plus transmis aux firewalls, et donc la synchronisation entre les deux firewall échoue.

La raison est que le firewall envoie un rapport d’adhésion uniquement au moment de l’activation de l’interface ou à la reception d’une requête IGMP. L’interface du Firewall s’inscrit donc bien au moment où l’interface est activée, mais ensuite comme plus aucun message IGMP n’est envoyé, le switch retire ce port au bout d’un timeout

En effet, c’est normalement le rôle du routeur multicast d’envoyer régulièrement des requêtes IGMP.

Etant donné qu’aucun routeur multicast n’est présent sur notre vlan, nous allons utiliser notre switch pour combler ce manque grâce à la fonctionnalité « querier« 

Voici la configuration sur un Nexus 7000 :

vlan configuration 183
ip igmp snooping querier 10.0.0.1

On peut configurer le querier sur deux switches pour avoir de la redondance. Le querier sur le switch secondaire sera désactivé tant qu’un querier avec une IP inférieure numériquement sera observée :

switch# sh ip igmp snooping vlan 183
IGMP Snooping information for vlan 183
IGMP snooping enabled
Lookup mode: IP
Optimised Multicast Flood (OMF) enabled
IGMP querier present, address: 10.0.0.1, version: 3, i/f Po1
Querier interval: 125 secs
Querier last member query interval: 1 secs
Querier robustness: 2
Switch-querier enabled, address 10.0.0.2, currently not running

Une fois que notre querier est configuré, le Firewall répondra aux demandes IGMP, ce qui permettra au switch de garder son interface dans le groupe IGMP