Hallo!
Ich habe hier zwei OpenBSD 4.0 Firewalls mit CARP und PFSync laufen. Die Konfiguration entspricht im Wesentlichen der aus dem PF-Howto. Ich habe also carp.preempt enabled und die PF-Regeln entsprechend angepasst.
Die CARP-interfaces sehen so aus:
Entsprechend sind die anderen Interfaces konfiguriert und auf der MasterFW ist natürlich advskew 50.
Es funktioniert auch soweit, dass die FW mit dem niedrigeren advskew Master wird und der Traffic über sie läuft. Beim Reboot des Masters wird der Backup kurz zum Master bis der eigentliche Master wieder da ist - da also kein Problem.
Wenn jetzt aber beide Firewalls laufen und ich verbinde mich per SSH auf die CARP-IP (192.168.0.1 in dem Fall), kommt es immer nach wenigen Zeilen zum Verbindungsabbruch. Verbinde ich mich mit der normalen IP, die das physikalische Interface hat, gibt es keine Probleme.
Ein TCPdump zeigt:
Eigentlich sollte die Firewall mit dem höheren advskew doch erkennen, dass die andere "geeigneter" ist und erst gar keine advertisements senden...
Hat vielleicht jemand eine Idee wo hier das Problem liegen könnte?
Vielen Dank,
Till
Ich habe hier zwei OpenBSD 4.0 Firewalls mit CARP und PFSync laufen. Die Konfiguration entspricht im Wesentlichen der aus dem PF-Howto. Ich habe also carp.preempt enabled und die PF-Regeln entsprechend angepasst.
Die CARP-interfaces sehen so aus:
Code:
carp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
carp: BACKUP carpdev em2 vhid 1 advbase 1 advskew 100
groups: carp
inet6 fe80::200:5eff:fe00:101%carp2 prefixlen 64 scopeid 0xb
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
Es funktioniert auch soweit, dass die FW mit dem niedrigeren advskew Master wird und der Traffic über sie läuft. Beim Reboot des Masters wird der Backup kurz zum Master bis der eigentliche Master wieder da ist - da also kein Problem.
Wenn jetzt aber beide Firewalls laufen und ich verbinde mich per SSH auf die CARP-IP (192.168.0.1 in dem Fall), kommt es immer nach wenigen Zeilen zum Verbindungsabbruch. Verbinde ich mich mit der normalen IP, die das physikalische Interface hat, gibt es keine Probleme.
Ein TCPdump zeigt:
Code:
# tcpdump -i em1 ether multicast
tcpdump: WARNING: em1: no IPv4 address assigned
tcpdump: listening on em1, link-type EN10MB
19:52:27.790682 CARPv2-advertise 36: vhid=1 advbase=1 advskew=50 demote=0 (DF) [tos 0x10]
19:52:29.000777 CARPv2-advertise 36: vhid=1 advbase=1 advskew=50 demote=0 (DF) [tos 0x10]
19:52:29.990114 CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10]
19:52:29.990241 fe80::20e:cff:fe83:cf0b > ff02::12: ip-proto-112 36
19:52:29.990246 arp who-has 192.168.0.1 tell 192.168.0.1
19:52:30.210853 CARPv2-advertise 36: vhid=1 advbase=1 advskew=50 demote=0 (DF) [tos 0x10]
19:52:31.420843 CARPv2-advertise 36: vhid=1 advbase=1 advskew=50 demote=0 (DF) [tos 0x10]
19:52:32.630939 CARPv2-advertise 36: vhid=1 advbase=1 advskew=50 demote=0 (DF) [tos 0x10]
19:52:33.620159 CARPv2-advertise 36: vhid=1 advbase=1 advskew=100 demote=0 (DF) [tos 0x10]
19:52:33.620169 fe80::20e:cff:fe83:cf0b > ff02::12: ip-proto-112 36
19:52:33.620175 arp who-has 192.168.0.1 tell 192.168.0.1
Eigentlich sollte die Firewall mit dem höheren advskew doch erkennen, dass die andere "geeigneter" ist und erst gar keine advertisements senden...
Hat vielleicht jemand eine Idee wo hier das Problem liegen könnte?
Vielen Dank,
Till