Messages

Waiting very long now, when will this be fixed?

These latency spikes exisit up to 25.10.1_2

Hallo,

mein schon etwas älterer klassisch aufgebauter HA-Cluster (derzeit 25.4.3 Business) erkennt keine LAN-Ausfälle mehr.
Hatte gestern einen Ausfall eines LAN-Switches wo die MASTER verbunden ist und es tat sich nichts, kein Failover oder ähnliches. Nichts in den Logfiles zu finden!
Das ging früher einwandfrei.
Habt ihr da einen Tip, wo ich da nachsehen könnte?

Oder wird da zwingend ein Linkdown-Event benötigt?

Also das klingt bei mir nicht nach "aus dem Lehrbuch" gebaut, sondern nach einer ziemlichen Bastellösung. Bin da bei Patricks letztem Post, das sieht für mich eher falsch aus.

Cheers

Danke für dein Feedback.
Wie würde eine eine "richtigere" Lösung aussehen?

[really]

We were testing with this regarding the kernel panic issue:

# opnsense-patch https://github.com/opnsense/core/commit/c8497ac14603

It needs a cron apply or reboot.  It will only reload the aliases twice per hours at the expense of the update interval. It has downsides, but we were discussion making it configurable for some edge cases like this.


Cheers,
Franco

Is this patch compatible with 25.4 ?
We really need this to made it configurable. In the meantime, the 1/31 would help us alot.
One of our customer has some problems with the constant minutely latency spikes with VoIP.

Here we have similar aliases (about 150) with average 3 million entries.
Reducing these to 50% does not help, the latency spikes are still there.

OPNSense 25.4 / HP DL 360 G9 / Xeon E5 2690v4 256 GB RAM

Aliases in einem anderen Subnetz sollten doch ebenfalls möglich sein. Ich würde aber unabhängig von CARP den Sinn hinterfragen.

"Sollte" ist gut. Damals hat das eben nicht funktioniert. Der Sinn war eine seamless Migration bestehender Strukturen.
Hätte ich die Möglichkeit, diese Geschichte komplett neu zu machen, hätte ich diese Probleme nicht.

Werde mir mal eine Teststellung virtualisieren und das Szenario nachspielen, vielleicht funktioniert ja inzwischen das mit den IP-Aliasen auf dem LAN mit CARP.

Wie kommt man auf die Idee, das anders zu machen? ;-) Also was soll das bringen?

@Patrick,
die beiden fixen IPs und die "Haupt-CARP-VIP" sind natürlich im selben Netz.
Habe aber zusätzliche CARP-VIPs anlegen müssen (mit anderen Netzen), da ja IP-Aliase nicht funktionierten.

Nein, von innen.

Es wurde eine öffentliche IP (zB. 92.123.123.123) bereitgestellt (via IP-Alias an der einzigen WAN-CARP-VIP).
Dann gibt es für zB. ein LAN-Netzwerk (zB. 172.16.10.0/24), die LAN-CARP-VIP wär dann 172.16.10.1/24.
Eingehendes & ausgehendes NAT ist so angelegt, dass NUR dieser Adressraum verwendet/erreicht werden kann (auch mit floating rules).

Natürlich haben die "echten" LAN-IPs der OPNSenses einen anderen Adressbereich, zB. 192.168.20.1 & 192.168.20.2.

Wenn ich zB. einen PC an der LAN-CARP-VIP anschliesse mit 172.16.10.100/24 mit Gateway 172.16.10.1, funktioniert alles wunderbar.
Traffic wird einwandfrei rausgenatet und rein.
Wenn man dann aber von diesem PC ein TCP-Traceroute nach 8.8.8.8 absetzt, sieht man leider die 192.168.20.1 anstatt 172.16.10.1 !

Und genau das ist das Problem.
Ich könnte als hauruck-Lösung ICMP deaktivieren oder umleiten, aber dann verliere ich die PMTU-Geschichte.

Nur zur Ergänzung:

Mir geht es eigentlich ja nur darum, einen externen "Störenfried", der permanent mit Traceroute/Tracert mir intern mein Netzwerk scannt und dann blöde Fragen stellt. Per ICMP UDP wird eh nichts angezeigt, per ICMP TCP aber schon.

[DAMALS]

@Patrick,

kann das hier jetzt auch grad nicht nachstellen. Damals gings am WAN einwandfrei mit den Aliases (inkl. HA/Failover), am LAN war sofort die Verbindung weg.
Daher DAMALS der Weg über die Carp-Vips.

Verstehe. Da hab ich was gelernt.
Wieder mal eine ziemliche, unlogische Eigenwilligkeit von OPNsense. Auf anderen Systemen funktionieren Aliase, die auf der CARP VIP aufsitzen, wunderbar und erleichtern das Setup und belasten nicht unnötig das Netzwerk. Beim Failover wandern sämtliche Aliase mit der CARP auf die andere Instanz.

Nur zur Info, die Erkenntnis war im Jahre 2022, eventuell hat sich in der Zwischenheit ja was getan.

Erstmal danke für die Antwort.
Carp-VIPs im Lan, weil Aliases nicht funktionieren und ich hier separieren muss.

Dachte es mir schon, dass dieses Verhalten nicht änderbar ist.
Ist nur unangenehm, wenn ein Kunde die originale Struktur über simples Traceroute herausfinden kann (Sicherheitsthema).

Hier das Ursprungsthema:
https://forum.opnsense.org/index.php?topic=30985.0

Hallo an alle,

habe ein spezielles Problem:
Es geht um ein HA-Setup mit 2 OPNSenses, aufgebaut aus "dem Lehrbuch".

WAN hat eine virtuelle öffentliche CARP IP (und 2 normale)
LAN hat mehrere virtuelle CARP IPs (und 2 normale)

Soweit alles gut, nur wenn ein Rechner, der an einer virtuellen IP (LAN) angebunden ist, ein Traceroute macht, bekommt er immer die "physische" IP der ersten OPNSense angezeigt anstatt die der virtuellen. Gibt es da eine Möglichkeit, dies zu ändern?
Outbound NAT ist eingerichtet, ebenso die dazugehörigen floating rules.

@franco

is this patch included in 25.1.4 now?

No, you are wrong.

Code Select Expand

1,31    *       *       *       *       (/usr/local/bin/flock -n -E 0 -o /tmp/filter_update_tables.lock /usr/local/opnsense/scripts/filter/update_tables.py) > /dev/null

Use crontab -e  and not the GUI

Yes, the minute latency spikes are gone.