Solución 1:
Los paquetes no pasan entre máquinas en la interfaz em1 (lo que provoca un escenario de cerebro dividido como afirma Mike).
- compruebe su cortafuegos para asegurarse de que no se capturen paquetes
- verifique su red para asegurarse de que em1 sea la misma red en ambas máquinas
Este es un ejemplo de cómo se ve uno de los paquetes:
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)
Solución 2:
En mi caso, tuve que permitir el tráfico de multidifusión a través del firewall a 224.0.0.18 , para ufw:
ufw allow from 224.0.0.18
ufw allow to 224.0.0.18
Esto me ayudó.
Solución 3:
En mi caso, para CentOS/RHEL 8 solo tuve que permitir la regla enriquecida del firewall para el protocolo vrrp para resolver este problema de cerebro dividido de Keepalived en el que ambos servidores tenían la dirección IP VIP. Tuve que agregar el indicador de kernel sysctl para permitir que HAProxy se vincule a una IP VIP no local.
Para sysctl, agregue net.ipv4.ip_nonlocal_bind = 1 en /etc/sysctl.conf archivo y luego hacer un sysctl -p para recargar la configuración de sysctl. Necesitaba esto NO para el escenario de cerebro dividido de Keepalived, sino para que HAProxy se vincule a su propia dirección IP para las estadísticas (por ejemplo, vincule 192.168.0.10:1492/stats) y se vincule a la dirección VIP (IP virtual) para la web de equilibrio de carga tráfico (vincular 192.168.0.34:80 y vincular 192.168.0.34:443). De lo contrario, el servicio HAProxy no pudo comenzar indicando que no puede vincularse a los puertos 80 y 443 solo con la dirección IP VIP. Estaba haciendo esto para evitar tener que enlazar *:80 y enlazar *:443. Además, se siente como una obviedad, pero se pasa por alto fácilmente, verifique si ha permitido el puerto que está utilizando para las estadísticas a través del firewall si no puede acceder a la página de estadísticas.
Para el cortafuegos, ejecute los siguientes comandos:
# firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
# firewall-cmd --reload
Encontré estas banderas y otra información directamente de la documentación de RedHat para HAProxy y Keepalived:
Referencia del cortafuegos:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-lvs-connect-vsa
Referencia de indicador de enlace no local (esto se usó para HAProxy, ya que no estaba usando Keepalived para el equilibrio de carga):https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-initial -configuración-reenvío-vsa
Solo HAProxy FYI:si HAProxy aún no se vincula a los puertos, es posible que desee ver el buen bloqueo de SELinux. Para mí, en CentOS 8 tuve que hacer un semanage port -a -t http_port_t -p tcp 1492 para mi página de estadísticas de HAProxy.