F5 - Cluster : Tous les VirtualServers ne basculent pas

Retour d'expérience sur un failover qui s'est mal passé entre deux noeuds F5 BIGIP.

Sur une cinquantaine de virtualservers configurés, 6 n'ont pas basculé lors d'un failover entre l'actif et le passif.

Comment est-ce possible ? Pourquoi 10% des virtual servers (VS) configurés n'ont pas basculés ?

1ère étape : Vérifier le traffic-group

Est-ce que ces VS qui n'ont pas basculés sont bien dans le trafic group partagé (floating traffic group) entre mes deux boitiers ?

Pour le vérifier, il faut se rendre dans Local Traffic > Virtual Servers > Virtual Address List. Et apparemment, c'est bien le cas :

2ème étape: Réflechir davantage.

Je me le répète souvent, le plus efficace selon moi dans un diagnostic, c'est de revenir aux bases, et aux concepts.

C'est la que je me pose des questions : Comment est censé fonctionner la bascule ?

Au niveau routage, le pare-feu en amont connait bien le next hop pour accéder aux virtualservers. La piste d'un problème de routage est eliminé, et puis d'ailleurs c'est impossible si ça fonctionne correctement sur un noeud, ça ne peut pas etre lié à un problème de routage étant donné qu'ils partagent les mêmes sous-réseaux.

Je me dirige alors vers la vérification de la table ARP du pare-feu. Le constat est clair et sans appel :

Les virtualservers qui ont basculé correctement ont la bonne adresse mac dans la table ARP du pare-feu. Ceux n'ayant pas basculé, ont encore l'adresse MAC du boitier précedemment actif.

3ème etape: Je chauffe.

Effectivement, le problème commence à être bien identifié. Sur le Palo Alto, je me rends compte que lorsque je bascule, les 6 virtualservers "ne suivent pas" et gardent toujours l'adresse MAC de l'ancien noeud actif.

D'où me vient cette question : Pourquoi 90% des VS se retrouvent avec la bonne adresse mac dans la table ARP et pas les 10% restants ?

4ème étape : Passage en mode detective - TCPDUMP à la rescousse

Un must have, must use, must know. Tcpdump pourra clairement vous sortir de bon nombres de galères. Quand on accuse le réseau d'être la cause de soucis, il sera votre plus grand allié pour vous défendre.

Je décide donc de prendre une capture de tout le trafic ARP sur les F5.

Le scénario est plutôt simple. Je lance mes commandes tcpdump et je force to Standby le noeud actif. A la fin de la bascule, je stope la capture.

tcpdump -vnni 0.0 arp -w ARPcapture_f5-1.pcap
tcpdump -vnni 0.0 arp -w ARPcapture_f5-2.pcap

Je recupère mes fichiers pcap pour les ouvrir avec Wireshark. J'analyse les fichiers et je vois clairement un grand nombre de gratuitous ARP. Mon analyse confirme le comportement observé, les 6 virtualservers n'envoient jamais de gratuitous ARP pour "prevenir de la bascule" et donc du changement d'adresse mac correspondant à ces IPs.

Egalement, je me rends compte que les six virtualservers ne sont pas dans le meme sous-réseau que les autres virtualservers qui basculent bien, et que les SelfIP sont dans le meme sous-réseau que les virtualservers qui basculent correctement.

Le problème vient donc de là. F5 ne semble pas envoyer de Gratuitous ARP pour des adresses d'objets qui n'ont pas de SelfIP dans le même sous-réseau.

Et ceci a bien été décrit dans une KB (K11880) F5 intitulé : "BIG-IP objects may not send GARP requests during failover".

En effet, F5 explique que dans la configuration, il est permis de créer des objets avec des adresses IP qui ne sont pas dans les memes sous-réseaux que les SelfIP configurés ou lorsqu'aucun VLAN n'est associé. En l'occurence, la conséquence c'est qu'il n'enverra jamais de gratuitous ARP pour les objets configurés de cette manière.

Pour résoudre ce problème, deux solutions :

• Configurer une SelfIP dans le meme sous-réseau que les objets problématiques
• Configurer le Mac Masquerade pour le traffic group correspondant

Faites vous une faveur ! Configurez systématiquement le Mac Masquerade lorsque c'est possible, ça ne fera qu'améliorer les temps de bascule et vous permettra de ne pas dépendre du protocole ARP.