Un provider presso cui si trovano dei server di un nostro cliente ci segnala di aver riscontrato un traffico anomalo su alcune porte di uno switch dell’infrastruttura del cliente:
Aug 18 16:01:53.911: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:5E:00:00:01 in vlan 295 is moving from port Gi1/16 to port Gi1/9
Aug 18 16:01:53.911: %C4K_EBM-4-HOSTFLAPPING: Host 00:00:5E:00:00:01 in vlan 295 is moving from port Gi1/9 to port Gi1/16
In pratica quel MAC address passava di continuo da una porta all’altra.
Un’analisi approfondita ci ha permesso di scoprire che quel MAC address (che è particolare) è utilizzato da un ben preciso protocollo di rete, denominaito VRRP (Virtual Router Redundancy Protocol). In particolare, i primi 5 gruppi di cifre sono fissi, mentre l’ultimo identifica il “Router Virtuale” (vedi qua per approfondimenti su VRRP).
Il VRRP viene utilizzato, tra gli altri, da ucarp che è il software usato da Zenload per gestire l’alta disponibilità tra i due nodi del cluster HA; in particolare Zenload usa come ultime due cifre il parametro ClusterID, che va definito quando si creaa il cluster HA (di default vale 01)
Se, come nel nostro caso, quel parametro non viene cambiato, tutti i cluster hanno ID=1 e quindi per tutti il MAC address vale esattamente 00:00:5E:00:00:01, vale a dire il valore riscontrato.
Purtroppo, come per molti altri parametri di configurazione del Cluster HA di Zenload, una volta che lo si è definito, non è più possibile cambiarlo. Abbiamo pertanto provveduto, per ogni Zenload, a “smontare” il cluster HA e a rifarlo con l’ID corretto.
Alcune considerazioni:
1) Tutta questa considerazione vale all’interno di ogni singolo troncone di rete (le richieste di VRRP per cercare gli altri router sono inviate in multicast all’IP 224.0.0.18). Quindi in due tronconi di rete diversi ci possono essere due cluster con ClusterID=1, tanto non si parleranno mai. Questo significa anche che non è possibile fare un cluster HA di Zenload con i nodi su due tronconi di rete diversi.
2) Per debuggare il problema occorre posizionrsi su un server nella stessa sottorete e usare il comando: tcpdump -e host 224.0.0.18. Occorre verificare nell’output del comando che in ogni riga a un certo hostname corrisponda uno e un solo ID e viceversa.
3) Nel fare il lavoro abbiamo trovato quelo che a nostro avviso è un BUG : il parametro ClusterID viene richiamato da due diversi script: in uno viene correttamente letto dal file di configurazione, mentre in /etc/init.d/zenloadbalacer (che fa partire il servizio zenload all’avvio) non è parametrizzato e vale sempre 1, creando dei problemi. Per ora l’unica soluzione è editare a mano il file in questione inserendo il corretto valore dell’ID (cercare le occorrenze di vhid=1 e sostituirle con l’ID assegnato al cluster in fase di setup, sono solo 3)