解決策 1:
パケットが em1 インターフェイス上のマシン間を通過していません (Mike が述べているように、スプリット ブレイン シナリオが発生しています)。
- ファイアウォールをチェックして、パケットが捕捉されていないことを確認してください
- ネットワークをチェックして、em1 が両方のマシンで同じネットワークであることを確認してください
以下は、パケットの 1 つがどのように見えるかの例です:
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)
解決策 2:
私の場合、ファイアウォールを通過して 224.0.0.18 へのマルチキャスト トラフィックを許可する必要がありました。 、ufw の場合:
ufw allow from 224.0.0.18
ufw allow to 224.0.0.18
これは役に立ちました。
解決策 3:
私の場合、CentOS/RHEL 8 では、両方のサーバーが VIP IP アドレスを保持していたこの Keepalived スプリットブレインの問題を解決するために、vrrp プロトコルのファイアウォール リッチ ルールを許可するだけで済みました。 HAProxy が非ローカル VIP IP にバインドできるようにするために、sysctl カーネル フラグを追加する必要がありました。
sysctl の場合、net.ipv4.ip_nonlocal_bind = 1 を追加します /etc/sysctl.conf で ファイルを作成してから sysctl -p を実行します sysctl 設定をリロードするため。これは、Keepalived スプリットブレイン シナリオではなく、HAProxy を統計用に独自の IP アドレスにバインドし (例:バインド 192.168.0.10:1492/stats)、Web 負荷分散用に VIP (仮想 IP) アドレスにバインドするために必要でした。トラフィック (バインド 192.168.0.34:80 およびバインド 192.168.0.34:443)。そうしないと、HAProxy サービスは開始に失敗し、VIP IP アドレスのみではポート 80 および 443 にバインドできないことが示されました。 bind *:80 と bind *:443 を回避するためにこれを行っていました。また、統計ページにアクセスできない場合は、統計に使用しているポートがファイアウォールを通過することを許可しているかどうかを確認してください。
ファイアウォールの場合、次のコマンドを実行します:
# firewall-cmd --add-rich-rule='rule protocol value="vrrp" accept' --permanent
# firewall-cmd --reload
これらのフラグとその他の情報は、HAProxy と Keepalived の RedHat ドキュメントから直接見つけました:
ファイアウォールのリファレンス:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-lvs-connect-vsa
非ローカル バインド フラグの参照 (負荷分散に Keepalived を使用していないため、これは HAProxy に使用されました):https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/load_balancer_administration/s1-initial -setup-forwarding-vsa
参考までに、HAProxy のみ:HAProxy がまだポートにバインドできない場合は、それをブロックしている古き良き SELinux を調べてみてください。私の場合、CentOS 8 では semanage port -a -t http_port_t -p tcp 1492 を実行する必要がありました 私のHAProxy統計ページのために。