OPNsense Forum
International Forums => German - Deutsch => Topic started by: ruffy91 on April 03, 2018, 10:01:42 pm
-
Hallo!
Wir haben einen Cluster aus 2 APU3C4 gebaut.
Wir setzen OPNSense 18.1.5 ein.
Darauf sind 4 CARP Virtual IPs auf VLANs auf einem Interface (igb1).
Mittels CARP Maintenance Mode können wir die VIPs beliebig hin und her schieben, was hervorragend funktioniert.
Weiterhin sehen wir jeweils die CARP Pakete auf beiden Firewalls (mit tcpdump).
Wenn wir igb1 auf dem Master trennen (Stecker ziehen) geht der Master Status auf allen 4 Interfaces schön auf die andere Firewall über.
Sobald igb1 wieder verbunden wird wird es lustig.
Der CARP Status verschwindet auf zufälligen Interfaces und wird auf Firewall A oder B Master.
z.B.
Vor Failover:
WAN: Master WAN: Backup
LAN: Master LAN: Backup
OPT1: Master OPT1: Backup
OPT2: Master OPT2: Backup
Bei Failover:
WAN: Init WAN: Master
LAN: Init LAN: Master
OPT1: Init OPT1: Master
OPT2: Init OPT2: Master
Nach Failover z.B.:
WAN: Master WAN: Backup
LAN: (Keine Angabe!) LAN: Master
OPT1: Master OPT1: Backup
OPT2: (Keine Angabe!) OPT2: Master
Die CARP Konfig scheint auf betroffenen Interfaces komplett zu verschwinden, dadurch bleibt die IP natürlich auf der 2. Firewall da sie der einzige Teilnehmer des CARP ist. Erst ein Reboot beider Firewalls scheint zu helfen.
Hat jemand einen Lösungsvorschlag oder eine Idee weshalb die Konfig verloren geht?
-
> Die CARP Konfig scheint auf betroffenen Interfaces komplett zu verschwinden
Scheint? Ist? Tut sie? Ein CARP Cluster wird vom Master mit Konfiguration versorgt, also entweder gibt es die VIP/CARP Konfiguration noch oder nicht. Ist es also noch konfiguriert oder nicht?
Ein Split Brain auf nur einem oder zwei Interfaces ist meist ein Kommunikationsproblem, wenn sich die beiden Geräte nicht sauber sehen. Vorher scheint es wohl so zu sein, aber nach "Abziehen" vom Interface nicht. Da fragt man sich, ob nach dem wiederfinden des physikalischen Interfaces vielleicht was mit den VLANs und/oder dem Switch nicht stimmt. Einfach mal die IPs der Geräte im entsprechenden VLAN pingen, wo beide Master sind. Wenn sie sich da nicht sehen, ist auf dem Layer2/3 was schief.
-
Hallo JeGr,
Ein Split Brain ist es nicht, es sind nie 2 Master aktiv.
Weiterhin sehe ich mittels tcpdump immer die CARP Pakete des jeweiligen Masters auf beiden Firewalls.
Es ist also immer Firewall A Master wie vorgesehen, ausser nach einem Failover wo Firewall A dann plötzlich werder Master noch Backup ist. Firewall B übernimmt dann den Master Status, da Firewall A ja keine CARP Pakete sendet.
Die Virtual IP wird auf Firewall A weiterhin im GUI angezeigt, aber wo normalerweise Master, Backup oder Init steht wird nichts angezeigt. Wie nennt sich dieser Status?
Danke für eure Hilfe!
-
Wir haben heute noch auf andere Hardware gewechselt (Huawei 1288H V5 mit Intel X722 2x 1GbE + 2x 10GB SFP+).
Jetzt haben wir Split Brain mit 2 Master.
Wir sehen auf dem Switch Port von Firewall B CARP Pakete für Master UND Slave IP. (Mit Port-Mirror und Wireshark überprüft)
Mit tcpdump auf der Firewall B sehen wir aber nur die Pakete der Firewall B und mit tcpdump auf Firewall A nur die von Firewall A.
Die Konfig der Interfaces sieht so aus:
ixl3: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=6000a8<VLAN_MTU,JUMBO_MTU,VLAN_HWCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
ether 48:8e:ef:d8:c5:7f
hwaddr 48:8e:ef:d8:c5:7f
inet6 fe80::4a8e:efff:fed8:c57f%ixl3 prefixlen 64 scopeid 0x4
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
inet 127.0.0.1 netmask 0xff000000
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: lo
enc0: flags=0<> metric 0 mtu 1536
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
groups: enc
pflog0: flags=100<PROMISC> metric 0 mtu 33160
groups: pflog
pfsync0: flags=0<> metric 0 mtu 1500
groups: pfsync
syncpeer: 224.0.0.240 maxupd: 128 defer: off
ixl3_vlan220: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 48:8e:ef:d8:c5:7f
inet6 fe80::4a8e:efff:fed8:c57f%ixl3_vlan220 prefixlen 64 scopeid 0x9
inet 192.168.220.12 netmask 0xffffff00 broadcast 192.168.220.255
inet 192.168.220.1 netmask 0xffffff00 broadcast 192.168.220.255 vhid 2
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 220 vlanpcp: 0 parent interface: ixl3
carp: BACKUP vhid 2 advbase 1 advskew 100
groups: vlan
ixl3_vlan221: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 48:8e:ef:d8:c5:7f
inet6 fe80::4a8e:efff:fed8:c57f%ixl3_vlan221 prefixlen 64 scopeid 0xa
inet 192.168.221.12 netmask 0xffffff00 broadcast 192.168.221.255
inet 192.168.221.1 netmask 0xffffff00 broadcast 192.168.221.255 vhid 1
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 221 vlanpcp: 0 parent interface: ixl3
carp: BACKUP vhid 1 advbase 1 advskew 100
groups: vlan
ixl3_vlan123: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 48:8e:ef:d8:c5:7f
inet6 fe80::4a8e:efff:fed8:c57f%ixl3_vlan123 prefixlen 64 scopeid 0xb
inet 192.168.123.12 netmask 0xffffff00 broadcast 192.168.123.255
inet 192.168.123.1 netmask 0xffffff00 broadcast 192.168.123.255 vhid 4
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 123 vlanpcp: 0 parent interface: ixl3
carp: MASTER vhid 4 advbase 1 advskew 100
groups: vlan
ixl3_vlan222: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
ether 48:8e:ef:d8:c5:7f
inet6 fe80::4a8e:efff:fed8:c57f%ixl3_vlan222 prefixlen 64 scopeid 0xc
inet 10.0.1.12 netmask 0xffffff00 broadcast 10.0.1.255
inet 10.0.1.10 netmask 0xffffff00 broadcast 10.0.1.255 vhid 3
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
vlan: 222 vlanpcp: 0 parent interface: ixl3
carp: MASTER vhid 3 advbase 1 advskew 100
-
Auf der neuen Hardware läuft es jetzt.
Wir hatten pfsync nach dieser Anleitung eingerichtet:
https://docs.opnsense.org/manual/how-tos/carp.html
Diese ist FALSCH! Sie erklärt, dass pfsync nur auf dem Master eingerichtet werden muss.
Richtig ist pfsync auf Master und Backup einzurichten, ansonsten kommt natürlich immer ein pfsync bulk fail.
Auf der APU Hardware läuft es aber auch mit diesen Einstellungen immer noch wie im 1. Post beschrieben.
Auf dem Master sieht dmesg nach Interface Down und wieder Up folgendermassen aus:
igb1: link state changed to DOWN
carp: 3@igb1_vlan221: MASTER -> INIT (hardware interface down)
carp: demoted by 240 to 240 (interface down)
igb1_vlan221: link state changed to DOWN
carp: 1@igb1_vlan220: MASTER -> INIT (hardware interface down)
carp: demoted by 240 to 480 (interface down)
igb1_vlan220: link state changed to DOWN
carp: 4@igb1_vlan222: MASTER -> INIT (hardware interface down)
carp: demoted by 240 to 720 (interface down)
igb1_vlan222: link state changed to DOWN
carp: 2@igb1_vlan230: MASTER -> INIT (hardware interface down)
carp: demoted by 240 to 960 (interface down)
igb1_vlan230: link state changed to DOWN
igb1: link state changed to UP
carp: 3@igb1_vlan221: INIT -> BACKUP (initialization complete)
carp: demoted by -240 to 720 (interface up)
igb1_vlan221: link state changed to UP
carp: 1@igb1_vlan220: INIT -> BACKUP (initialization complete)
carp: demoted by -240 to 480 (interface up)
igb1_vlan220: link state changed to UP
carp: 4@igb1_vlan222: INIT -> BACKUP (initialization complete)
carp: demoted by -240 to 240 (interface up)
igb1_vlan222: link state changed to UP
carp: 2@igb1_vlan230: INIT -> BACKUP (initialization complete)
carp: demoted by -240 to 0 (interface up)
igb1_vlan230: link state changed to UP
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan221: 3
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan221: 3
carp: 3@igb1_vlan221: BACKUP -> INIT (hardware interface up)
igb1_vlan221: promiscuous mode disabled
carp: 2@igb1_vlan230: BACKUP -> MASTER (master timed out)
ifa_maintain_loopback_route: insertion failed for interface igb1_vlan230: 17
carp: 4@igb1_vlan222: BACKUP -> MASTER (master timed out)
ifa_maintain_loopback_route: insertion failed for interface igb1_vlan222: 17
carp: 1@igb1_vlan220: BACKUP -> MASTER (master timed out)
ifa_maintain_loopback_route: insertion failed for interface igb1_vlan220: 17
carp: demoted by 240 to 240 (pfsync bulk start)
carp: demoted by -240 to 0 (pfsync bulk done)
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan220: 3
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan220: 3
carp: 1@igb1_vlan220: MASTER -> INIT (hardware interface up)
igb1_vlan220: promiscuous mode disabled
carp: demoted by 240 to 240 (pfsync bulk start)
carp: 4@igb1_vlan222: MASTER -> BACKUP (more frequent advertisement received)
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan222: 3
carp: 2@igb1_vlan230: MASTER -> BACKUP (more frequent advertisement received)
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan230: 3
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan222: 3
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan222: 3
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan222: 3
carp: 4@igb1_vlan222: BACKUP -> INIT (hardware interface up)
igb1_vlan222: promiscuous mode disabled
carp: demoted by -240 to 0 (pfsync bulk done)
carp: 2@igb1_vlan230: BACKUP -> MASTER (preempting a slower master)
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan230: 3
ifa_maintain_loopback_route: deletion failed for interface igb1_vlan230: 3
carp: 2@igb1_vlan230: MASTER -> INIT (hardware interface up)
igb1: promiscuous mode disabled
igb1_vlan230: promiscuous mode disabled
carp: demoted by 240 to 240 (pfsync bulk start)
carp: demoted by -240 to 0 (pfsync bulk done)
Alle CARP sind auf INIT und kommen nicht mehr hoch. Weshalb?
-
> Richtig ist pfsync auf Master und Backup einzurichten, ansonsten kommt natürlich immer ein pfsync bulk fail.
Inwiefern einzurichten? Dass jeweils der andere Node als PFSync Target benannt werden? Selbst wenn hier ein Knoten keine Einträge hat, sollte er die Daten per directed Multicast versenden. Nicht schön, sollte aber trotzdem nicht zu solch einem Verhalten führen.
Ansonsten ist das Verhalten extrem merkwürdig. Ist dein Log Top Down oder Bottom Up?
-
Die neusten Log Einträge sind zuunterst.
Auf dem Backup Node muss für pfSync zumindest Synchronize States aktiviert werden und das Synchronize Interface angegeben werden. Kann gut sein, dass es dann auch ohne Angabe der Peer IP funktioniert.
-
Sind auf allen Interfaces, die CARP enabled sind, beide IPs erreichbar gegenseitig? Sehen sich die Geräte selbst?
Sind alle Interfaces, auch OPTx in richtiger Reihenfolge auf beiden Nodes zugewiesen? Also sind die gleichen Interfaces (physisch wie logisch) auch den gleichen OPTs zugewiesen?
Da du im OP geschrieben hattest, dass nur LAN und OPT2 das komische Verhalten zeigen, ist an den beiden was besonderes? sind das VLANs und andere Physisch o.ä.?
Oder sind an genau den Interfaces noch weitere Geräte aktiv die Multicast Gruppen oder HSRP/VRRP sprechen? Bringt somit ggf. ein Wechsel der VHID etwas?
-
@ruffy91
Aber dazu muss er doch dann einen Remote Usernamen und ein Passwort angeben, damit der BACKUP Node weiß wohin er als welcher User etws syncen darf, oder liege ich damit jetzt daneben ?
-
@Wayne: Nein, der Backup Node darf gar nichts syncen, von den aktuellen States via pfsync mal abgesehen. Aber XMLRPC Sync darf der Backup NIE machen. Das wäre ein Loop Sync. Daher wird auch darauf hingewiesen, dass im Backup Zustand keine Konfigurationsänderungen gemacht werden sollten, da diese NUR von Master auf Backup gesynct werden, nicht andersrum.
-
Hallo zusammen.
Ruffy, hast du zu diesem Problem eine Lösung gefunden, oder bist du dabei geblieben die neue Hardware zu verwenden?
Ich verwende zwei APU2c4-Boards mit OPNsense 18.1.9 auf denen auf LAN und WAN-Interface CARP läuft. Bei einem Poweroff/Stromkabelziehen läuft alles wunderbar, der Failover ist schnell und läuft korrekt ab. Auch das Zurückswitchen läuft ohne Probleme.
Wenn ich jedoch ein Ethernet-Kabel ziehe oder den Switchport herunterfahre und anschließend wieder verbinde funktioniert zwar der Failover, aber danach zeigt sich bei mir das gleiche Verhalten. Auf dem Interface, welches den Link verloren hat wird kein CARP-Status mehr angezeigt und der zweite Host übernimmt hier den Master. Der Master des zweiten Interface bleibt beim ersten Host. Und das obwohl inet.carp.preempt=1 gesetzt ist. Zusätzlich habe ich beim Debugging derzeit noch net.inet.carp.senderr_demotion_factor=0 gesetzt, was jedoch auch nicht geholfen hat. Auch State-Sync auf dem Backup-Node hilft nicht. 18.1.4 war meine erste Version, damit war das Problem auch schon vorhanden. Das Problem wird anschließend nur durch einen Reboot des betroffenen Gates, oder durch temporäres Aus&An von CARP behoben.
Anbei ein Auszug aus dem Log. Mich verwundert warum der Promiscious Mode auf dem betroffenen Interface deaktiviert wird. Auch verstehe ich nicht, warum ich trotz eines nicht funktionierenden Interface (da dort kein CARP läuft) wieder promoted werde auf 0.
Von unten nach oben zu lesen:
#carp inactive on LAN port, carp master on WAN port (although net.inet.carp.preempt=1 is set)
Jun 12 11:24:35 opnsense: /usr/local/etc/rc.newwanip: Interface 'opt3' is disabled or empty, nothing to do.
Jun 12 11:24:35 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'ovpns1'
Jun 12 11:24:34 kernel: ovpns1: link state changed to UP
Jun 12 11:24:29 kernel: ovpns1: link state changed to DOWN
Jun 12 11:24:29 opnsense: /usr/local/etc/rc.carpmaster: Starting OpenVPN server instance on xxx.xxx.xxx.xxx - WAN_CARP because of transition to CARP master.
Jun 12 11:24:29 opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "MASTER" for vhid 2
Jun 12 11:24:28 kernel: carp: 2@igb1: BACKUP -> MASTER (preempting a slower master)
Jun 12 11:24:28 kernel: carp: demoted by -240 to 0 (pfsync bulk fail)
Jun 12 11:23:45 opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "BACKUP" for vhid 2
Jun 12 11:23:38 opnsense: /usr/local/etc/rc.newwanip: Interface 'opt3' is disabled or empty, nothing to do.
Jun 12 11:23:38 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'ovpns1'
Jun 12 11:23:37 kernel: ovpns1: link state changed to UP
Jun 12 11:23:32 kernel: ovpns1: link state changed to DOWN
Jun 12 11:23:32 opnsense: /usr/local/etc/rc.carpmaster: Starting OpenVPN server instance on xxx.xxx.xxx.xxx - WAN_CARP because of transition to CARP master.
Jun 12 11:23:32 opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "MASTER" for vhid 2
Jun 12 11:23:31 opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "MASTER" for vhid 1
Jun 12 11:23:28 opnsense: /usr/local/etc/rc.newwanip: Resyncing OpenVPN instances for interface LAN.
Jun 12 11:23:24 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv6 default route
Jun 12 11:23:24 opnsense: /usr/local/etc/rc.newwanip: ROUTING: skipping IPv4 default route
Jun 12 11:23:24 opnsense: /usr/local/etc/rc.newwanip: ROUTING: no IPv6 default gateway set, assuming wan
Jun 12 11:23:24 opnsense: /usr/local/etc/rc.newwanip: ROUTING: IPv4 default gateway set to wan
Jun 12 11:23:24 opnsense: /usr/local/etc/rc.newwanip: ROUTING: entering configure using 'lan'
Jun 12 11:23:22 kernel: ifa_maintain_loopback_route: deletion failed for interface igb1: 3
Jun 12 11:23:22 kernel: carp: 2@igb1: MASTER -> BACKUP (more frequent advertisement received)
Jun 12 11:23:22 kernel: carp: demoted by 240 to 240 (pfsync bulk start)
Jun 12 11:23:22 kernel: igb0: promiscuous mode disabled
Jun 12 11:23:22 kernel: carp: 1@igb0: MASTER -> INIT (hardware interface up)
Jun 12 11:23:22 kernel: ifa_maintain_loopback_route: deletion failed for interface igb0: 3
Jun 12 11:23:22 kernel: ifa_maintain_loopback_route: deletion failed for interface igb0: 3
Jun 12 11:23:22 opnsense: /usr/local/etc/rc.newwanip: The command '/sbin/ifconfig igb0 '192.168.123.1'/'24' alias vhid '1'' returned exit code '1', the output was 'ifconfig: ioctl (SIOCAIFADDR): Protocol not available'
Jun 12 11:23:22 opnsense: /usr/local/etc/rc.newwanip: On (IP address: 192.168.123.2) (interface: LAN[lan]) (real interface: igb0).
Jun 12 11:23:22 opnsense: /usr/local/etc/rc.newwanip: IP renewal is starting on 'igb0'
Jun 12 11:23:22 kernel: carp: 2@igb1: BACKUP -> MASTER (preempting a slower master)
Jun 12 11:23:21 kernel: ifa_maintain_loopback_route: insertion failed for interface igb0: 17
Jun 12 11:23:21 kernel: carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
Jun 12 11:23:21 opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.123.2 ::)
Jun 12 11:23:21 opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "BACKUP" for vhid 1
Jun 12 11:23:20 kernel: igb0: link state changed to UP
Jun 12 11:23:20 kernel: carp: demoted by -240 to 0 (interface up)
Jun 12 11:23:20 kernel: carp: 1@igb0: INIT -> BACKUP (initialization complete)
#enable port on switch#
Jun 12 11:22:50 opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "BACKUP" for vhid 2
Jun 12 11:22:50 opnsense: /usr/local/etc/rc.linkup: Hotplug event detected for LAN(lan) but ignoring since interface is configured with static IP (192.168.123.2 ::)
Jun 12 11:22:49 kernel: ifa_maintain_loopback_route: deletion failed for interface igb1: 3
Jun 12 11:22:49 kernel: carp: 2@igb1: MASTER -> BACKUP (more frequent advertisement received)
Jun 12 11:22:49 kernel: igb0: link state changed to DOWN
Jun 12 11:22:49 kernel: carp: demoted by 240 to 240 (interface down)
Jun 12 11:22:49 kernel: carp: 1@igb0: MASTER -> INIT (hardware interface down)
#disable Port on Switch#
###Edit: OPNsense Version hinzugefügt###
###Edit2: Temporäre Behebung hinzugefügt###
-
Hallo tt-ah
Ich habe keine Lösung gefunden und warte aktuell auf FreeBSD 11.2 als Unterbau, da wir ein ähnliches Problem bei neuerer Hardware haben und anscheinend 11.2 neue Intel Treiber bringt die besser funktionieren sollen. Dürfte aber noch bis Ende Jahr dauern.
-
Aktuell haben wir Updates für ixl und ixgbe vorgesehen für 18.7, also 11.1 mit Teilen von 11.2.
Grüsse
Franco
-
Okay, danke euch beiden für das Update.
Die Treiberupdates sehen für mich aber auch nach einem Schuss ins Dunkle aus :(
Ich vermute im Moment immer noch irgendeine Fehlkonfiguration, da die Systeme, welche wir verwenden, weit verbreitet in Gebrauch sind und ich von dieser Problematik jedoch bisher recht wenig gelesen habe...
Ich halte mal die Ohren steif und poste hier, sollte ich etwas finden können.
-
Mir ist etwas aufgefallen und zwar, daß advertising skew (advskew) bei Master und Backup den gleichen Wert hat:
carp: BACKUP vhid 2 advbase 1 advskew 100
carp: BACKUP vhid 1 advbase 1 advskew 100
carp: MASTER vhid 4 advbase 1 advskew 100
carp: MASTER vhid 3 advbase 1 advskew 100
Laut der man-Seite zu pfsync sollte man aber bei der Backup-Firewall einen höheren Wert, z.B. 100, verwenden. Für die Master-Firewall empfiehlt sich der Wert 0.
It is preferable that one firewall handle the forwarding of all the traffic, therefore the advskew on the backup firewall's carp(4) vhids should be set to something higher than the primary's.
https://www.freebsd.org/cgi/man.cgi?pfsync%284%29 (https://www.freebsd.org/cgi/man.cgi?pfsync%284%29)
Zum Verständnis:
advskew 0 is an optional parameter specifying how much to skew the advbase when sending CARP advertisements. The default value of advbase is one(1) which equates to sending a CARP advertisement 1/256 of a second. If the advskew is zero(0) then the advbase plus advskew still equals one; CARP advertisements will be sent out one per second. By manipulating advskew, the master CARP host can be chosen or forced. The lower the advskew value, the MORE preferred the host will be when choosing a master. The default is 0. Acceptable values are from 0 to 254. Notice the advskew on the master is 0 and the advskew on the backup is 100. If the BACKUP firewall (fw1) ever becomes the master the CARP advertisements will be sent out once every 1.391 seconds (advbase of 1 plus skew of 100/256 seconds).
https://calomel.org/pf_carp.html (https://calomel.org/pf_carp.html)
Vielleicht liegt es ja einfach daran.
-
Bei einem funktionierenden Sync sollte bei Anlage von Carp Interface die Skew auf dem Backup automatisch erhöht werden. Das ist dann auch grau hinterlegt wenn ich mich richtig erinnere.
-
hi,
ich klinke mich mal hier ein, da es danach aussieht, als wenn das Problem exakt dem entspricht, was wir hier haben: https://forum.opnsense.org/index.php?topic=8915.0
Ich versuche jetzt die Onboard Netzwerkkarte durch USB zu ersetzen (keine freien Slots/Ports mehr) und dann schauen wir, ob das Problem besteht. Ich vermute es wird funktionieren.
-
Wenn es funktioniert würde deine Theorie mit pfSense nicht ganz Sinn machen? Halt uns da mal auf dem Laufenden. Hast du auf GitHub in core schon nen issue dazu?
-
Abweichung bei mir wäre, dass der Promiscious Mode tatsächlich deaktiviert wird und nicht nach UP des Interfaces aktiviert wird.
(s. Log in früherem Post)
-
Der ifconfig-Fehler beim Durchlaufen von rc.newwanip killt den CARP-status, es gibt hier scheinbar einen Bug im BSD-Source.
Siehe https://github.com/opnsense/core/issues/2486 bzw. https://redmine.pfsense.org/issues/6892
-
Danke für die Info clystron!
Den Bug #6892 hatte ich auch gefunden, aber abgehakt, da er als resolved markiert war. Das neue Topic im Github ist aber sehr interessant! Also dann doch warten bis 18.7 ::)
-
Ich hab mir testweise einen Workaround gebastelt der das ifconfig Kommando einfach wiederholt wenn es fehlschlägt. Ideal ist das natürlich nicht aber es scheint zu wirken.
-
Mit clystrons Hilfe haben wir den Fix aus FreeBSD erfolgreich getestet und in die kommende Version 18.7 übernommen. :)
> Den Bug #6892 hatte ich auch gefunden, aber abgehakt, da er als resolved markiert war.
Ein Bug der 1 Jahr alt ist wobei wir schon vor 3 Jahren geforkt haben sollte skeptisch beäugt werden. ;)
Grüsse
Franco
-
Stimmt, da war ja was :-[
Cool, dass ihr es fixen konntet. Freue mich aufs Update :)
-
Oder gleich testen:
# opnsense-update -kr 18.1.9-next -n "snapshots\/dummy"
# /usr/local/etc/rc.reboot
Grüsse
Franco
-
Patch habe ich getestet, das Problem mit dem CARP-Interface tritt nicht mehr auf. 8)
Jedoch ist es nun wieder so, dass beim Ausfall eines Interfaces nur das eine Interface an den Slave abgegeben wird. Das zweite Interface bleibt beim Master :/
Das hatte vor dem Patch noch funktioniert. Das Tunable net.inet.carp.preempt "1" ist gesetzt...
Hat da jemand eine Idee?
Jun 28 14:58:05 kernel: carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
Jun 28 14:58:04 opnsense: /usr/local/etc/rc.carpmaster: Starting OpenVPN server instance on xxx.xxx.xxx.xxx - WAN_CARP because of transition to CARP master.
Jun 28 14:58:04 opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "MASTER" for vhid 2
Jun 28 14:58:04 kernel: carp: 2@igb1: BACKUP -> MASTER (preempting a slower master)
Jun 28 14:58:04 kernel: carp: demoted by -240 to 0 (pfsync bulk fail)
Jun 28 14:57:04 opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "BACKUP" for vhid 1
Jun 28 14:57:04 opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "xxx.xxx.xxx.xxx - WAN_CARP (2@igb1)" has resumed the state "BACKUP" for vhid 2
Jun 28 14:56:58 kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
Jun 28 14:56:58 kernel: carp: demoted by 240 to 240 (pfsync bulk start)
Jun 28 14:56:58 kernel: carp: 2@igb1: INIT -> BACKUP (initialization complete)
Jun 28 14:56:01 opnsense: /usr/local/etc/rc.carpmaster: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "MASTER" for vhid 1
Jun 28 14:56:00 kernel: carp: 1@igb0: BACKUP -> MASTER (preempting a slower master)
Jun 28 14:56:00 opnsense: /usr/local/etc/rc.carpbackup: Carp cluster member "192.168.123.1 - LAN_CARP (1@igb0)" has resumed the state "BACKUP" for vhid 1
Jun 28 14:56:00 kernel: carp: demoted by -240 to 0 (vhid removed)
Jun 28 14:55:59 kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
Jun 28 14:55:59 kernel: carp: demoted by 240 to 240 (interface down)
Jun 28 14:55:59 kernel: carp: 2@igb1: MASTER -> INIT (hardware interface down)
-
Preempt aber bitte nur auf dem Slave oder?
-
Hatte es auf beiden Systemen. Aber auch wenn es nur auf dem Slave eingerichtet ist, der Master wird ja trotz inaktivem Interface wieder auf 0 promoted:
Jun 28 14:56:00 kernel: carp: demoted by -240 to 0 (vhid removed)
Jun 28 14:55:59 kernel: carp: 1@igb0: MASTER -> BACKUP (more frequent advertisement received)
Jun 28 14:55:59 kernel: carp: demoted by 240 to 240 (interface down)
Dann wird der Slave das ja auch nicht übernehmen.
-
Also bei mir hat der Patch nichts in der Richtung geändert, mein Testsetup besteht aus zwei Firewalls mit LAN/WAN/DMZ und alle Interfaces wandern zum Slave wenn ich am Master eins abziehe.
Preempt ist bei mir auf beiden Hosts gesetzt, laut FreeBSD CARP-Manpage sollte das so sein ("Enable it on both hosts A and B")
Edit: was mich stutzig macht ist die "vhid removed" message die dann wieder zur Rückkehr auf 0 führt, die hab ich nicht und die sollte doch auch nicht sein würd ich sagen
Wolfgang
-
Preempt ist bei mir auf beiden Hosts gesetzt, laut FreeBSD CARP-Manpage sollte das so sein ("Enable it on both hosts A and B")
Das ist Geschmacksache .. ich mag die Primärfirewall immer Master haben wenn die auch i.O. ist.
-
Das ist Geschmacksache .. ich mag die Primärfirewall immer Master haben wenn die auch i.O. ist.
Genau das passiert bei mir auch, sobald die Primärmaschine wieder OK ist (link up oder reboot fertig oder,..) schaltet das Ganze zurück. Um ehrlich zu sein ist die Erklärung von Preempt im Detail für mich noch nicht klar, ich bin einfach der Empfehlung gefolgt und habe aktuell das Ergebnis das ich wollte.