Soluzione 1:
I pacchetti non passano tra le macchine sull'interfaccia em1 (causando uno scenario di cervello diviso come afferma Mike).
- controlla il tuo firewall per assicurarti che i pacchetti non vengano intercettati
- controlla la tua rete per assicurarti che em1 sia la stessa rete su entrambe le macchine
Ecco un esempio di come appare uno dei pacchetti:
Frame 2: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
Arrival Time: Jun 1, 2013 03:39:50.709520000 UTC
Epoch Time: 1370057990.709520000 seconds
[Time delta from previous captured frame: 0.000970000 seconds]
[Time delta from previous displayed frame: 0.000970000 seconds]
[Time since reference or first frame: 0.000970000 seconds]
Frame Number: 2
Frame Length: 54 bytes (432 bits)
Capture Length: 54 bytes (432 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ip:vrrp]
Ethernet II, Src: 00:25:90:83:b0:07 (00:25:90:83:b0:07), Dst: 01:00:5e:00:00:12 (01:00:5e:00:00:12)
Destination: 01:00:5e:00:00:12 (01:00:5e:00:00:12)
Address: 01:00:5e:00:00:12 (01:00:5e:00:00:12)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00:25:90:83:b0:07 (00:25:90:83:b0:07)
Address: 00:25:90:83:b0:07 (00:25:90:83:b0:07)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 10.0.10.11 (10.0.10.11), Dst: 224.0.0.18 (224.0.0.18)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
Total Length: 40
Identification: 0x8711 (34577)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment offset: 0
Time to live: 255
Protocol: VRRP (112)
Header checksum: 0x4037 [correct]
[Good: True]
[Bad: False]
Source: 10.0.10.11 (10.0.10.11)
Destination: 224.0.0.18 (224.0.0.18)
Virtual Router Redundancy Protocol
Version 2, Packet type 1 (Advertisement)
0010 .... = VRRP protocol version: 2
.... 0001 = VRRP packet type: Advertisement (1)
Virtual Rtr ID: 254
Priority: 151 (Non-default backup priority)
Addr Count: 1
Auth Type: No Authentication (0)
Adver Int: 1
Checksum: 0x3c01 [correct]
IP Address: 10.0.0.254 (10.0.0.254)
Soluzione 2:
Nel mio caso ho dovuto consentire il traffico multicast attraverso il firewall a 224.0.0.18 , per ufw:
ufw allow from 224.0.0.18
ufw allow to 224.0.0.18
Questo mi ha aiutato.
Soluzione 3:
Nel mio caso, per CentOS/RHEL 8 ho dovuto solo consentire la ricca regola del firewall per il protocollo vrrp per risolvere questo problema di split-brain Keepalived in cui entrambi i server contenevano l'indirizzo IP VIP. Ho dovuto aggiungere il flag del kernel sysctl per consentire a HAProxy di collegarsi all'IP VIP non locale.
Per sysctl, aggiungi net.ipv4.ip_nonlocal_bind = 1 in /etc/sysctl.conf file e quindi eseguire un sysctl -p per ricaricare la configurazione di sysctl. Ne avevo bisogno NON per lo scenario split-brain Keepalived ma per avere HAProxy associato al proprio indirizzo IP per le statistiche (es:bind 192.168.0.10:1492/stats) e associato all'indirizzo VIP (IP virtuale) per il web di bilanciamento del carico traffico (bind 192.168.0.34:80 e bind 192.168.0.34:443). In caso contrario, il servizio HAProxy non è stato avviato affermando che non può collegarsi alla porta 80 e 443 solo con l'indirizzo IP VIP. Stavo facendo questo per evitare di avere bind *:80 e bind *:443. Inoltre, sembra un gioco da ragazzi ma facilmente trascurabile, controlla se hai consentito la porta che stai utilizzando per le statistiche attraverso il firewall se non sei in grado di raggiungere la pagina delle statistiche.
Per il firewall, esegui i seguenti comandi:
# firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
# firewall-cmd --reload
Ho trovato questi flag e altre informazioni direttamente dalla documentazione di RedHat per HAProxy e Keepalived:
Riferimento firewall:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-lvs-connect-vsa
Riferimento al flag di bind non locale (questo è stato utilizzato per HAProxy anche se non stavo usando Keepalived per il bilanciamento del carico):https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-initial -setup-forwarding-vsa
Solo HAProxy FYI:se HAProxy ancora non riesce a collegarsi alle porte, potresti voler guardare il buon vecchio SELinux che lo blocca. Per me, su CentOS 8 ho dovuto fare un semanage port -a -t http_port_t -p tcp 1492 per la mia pagina delle statistiche HAProxy.