Topics

1

20.1 Legacy Series / 19.7 to v20.1/20.7 -> recurring high ping latency

« on: February 22, 2021, 09:45:19 am »

Hello,

since the upgrade from 19.7 to a higher version, we notified, that we have often a very high ping latency on our OpnSense Cluster. It happens only, of the packages goes through the OpnSense. We replaced the SFP+ modules, cleaned the fiber but .. since it happens on both physical hosts, we don't think, it's a network hardware issue.

What we have:

• SuperMicro X11SSH-TF
• 64GB DDR4
• Intel X520 (fiber)
• Intel X550 (copper)

I've attached a Grafana picture as you can see, that we have much "noise". These causes, that our MariaDB starts to switch our Write Master.
We have also an nearly identical setup on the other side (both clusters are connected via a darkfiber). I say nearly, because the firewall rules are a bit different (because of the reverse side), but we don't now ... that we configured a thing, that causes the ping latency with a higher version than 19.7.

We red about problems, if the OpnSense is a VM ... and some Pyhton scripts steal the CPU ...but our hosts are physical. We have no idea, where we can find this issue.

Any suggestions ?

cu denny

2

German - Deutsch / OPNsense 19.1.7: IPSEC Tunnel nicht "down" bei defekter Glasfaser (TX oder RX)

« on: July 30, 2019, 05:21:15 pm »

hi,

wir hatten gestern einen Ausfall bei der Verbindung zwischen zwei RZs, bei dem der RZ Betreiber versehentlich unsere Darkfiber in der Tür eingeklemmt hat. Das hatte zur Folge, dass wir ziemlich ins schwitzen kamen, bis die Ursache klar war.
Der Grund warum das Auffinden so lange gedauert hat war der, dass laut beiden OpenSense Clustern (19.1.7) das VPN wohl noch auf beiden Standorten "aktiv" war, aber es floss kein Verkehr durch.

Ich vermute, dass das Kabel nicht vollständig durchtrennt wurde, sondern nur soviel, dass entweder RX, oder TX kaputt war. Der Link muss also für die SFP+ (Single Mode 10km) noch "UP" gewesen sein.

Hat jemand schon einmal ein ähnliches Problem gehabt ?  Eigentlich hätte ich erwartet, dass IPSec Heartbeats sendet und beim Ausbleiben eben dieser die Verbindung beendet. Das hätte nämlich schneller  dafür gesorgt, dass Redis / MongoDB und Co darüber Bescheid gewusst und sich reorganisiert hätten. So waren wir gezwungen, am primären Standort den OpenSense Cluster zu rebooten. Erst ab diesem Moment als der OpnSense Cluster wieder da war, konnten wir einen Standort wieder in den regulären Betrieb versetzen.
Als der RZ Betreiber das Kabel ausgetauscht hatte, konnte auch der IPSec tunnel wieder in Betrieb genommen werden, um den zweiten Standort restaurieren.

Ich weiß von einem Kollegen, dass er ein ähnliches Phänomen hatte, aber mit einer Cisco :-)  Er hat darauf hin alle SFP+ Module ausgetauscht gegen welche, die nur eine "Faser" benötigen (also RX / TX  werden über Frequenzen verwaltet).

cu denny

3

German - Deutsch / UDP auf WAN, klappt nur mit [ x ]Disable reply-to on WAN rules

« on: May 10, 2019, 09:09:17 am »

Hi,

wir haben PFSense Hosts zu  OpnSense (19.1.7) umgebaut, damit wir das gleiche Konstrukt haben (aber mit 19.1), wie in unserem anderen RZ. 
Leider sind wir auf das Phänomen gestoßen, dass UDP nicht klappt.  Unser Interface "DMZ(WAN)" hat alle passenden Regeln und es findet sich auch kein Block in der Log. Durch Zufall haben wir die Funktion  [ x ]Disable reply-to on WAN rules akiviert und siehe da, plötzlich ging auch UDP.
In unserem RZ B, ist diese Funktioniert nicht aktiv, der Rest ist aber sonst identisch. Wir haben auch kein Multiwan etc. sondern das WAN Interface ist bei uns das DMZ.

Die ersten Probleme mit UDP kamen auf, als ich SNMP auf der OpnSense eingerichtet habe und es einfach nicht klappen wollte. Es hat sich gezeigt, auf der OpnSense funktionierte mein SNMPwalk, aber vom Monitoring Host nicht (dieser geht auf das DMZ(WAN) Interface).
Wird die Firewall deaktiviert (pfctl -d) klappt alles. Setzen wir die eingangs erwähnte Option ... klappt es ebenfalls.

Wir sind daher ein wenig ratlos ... wo das Problem liegt. Ich sollte nicht unerwähnt lassen, dass wir die Aliase von unserem anderen RZ mittels XML Änderung importiert haben, ebenso wie die Firewallregeln.
 Meine UDP Probleme (bezogen auf SNMP) hatte ich aber noch vor den Imports.

cu denny

4

German - Deutsch / Carp Problem auf Supermicro X11SSH-F und shared IPMI/LAN Interface

« on: June 14, 2018, 08:39:57 am »

hi,

wir haben ein Problem mit Carp, welches wir nicht gelöst bekommen. Wir haben die aktuellste Version von OpnSense und IPMI Firmware. Als Mainboard haben wir je ein Supermicro X11SSH-F, welches über zwei reguläre 10Gb/s Netzwerkports und einem Shared IPMI/LAN mit 1Gb/s verfügt. Die zwei 10Gb haben VLAN aktiv und funktionieren ausgesprochen gut und hatten da nie ein Problem. Bei dem IPMI/LAN dagegen funktioniert CARP überhaupt nicht. Beim Schwenk verbleibt der Status je im Init.

Was ich im dmesg für z.B ix0 (10Gb/s)

Code: [Select]

....
ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0xe020-0xe03f mem 0xdfc80000-0xdfcfffff,0xdfd04000-0xdfd07fff irq 17 at device 0.0 on pci2
ix0: Using MSIX interrupts with 9 vectors
ix0: Ethernet address: 90:e2:ba:db:48:78
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0: netmap queues/slots: TX 8/2048, RX 8/2048
ix0: link state changed to UP
ix0: promiscuous mode enabled
carp: 50@ix0: INIT -> BACKUP (initialization complete)
carp: 55@ix0: INIT -> BACKUP (initialization complete)
carp: 50@ix0: BACKUP -> MASTER (master timed out)
carp: 55@ix0: BACKUP -> MASTER (master timed out)
...

Und nun für ix2 (1Gb/s shared)

Code: [Select]

ix2: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> mem 0xdf800000-0xdf9fffff,0xdfa04000-0xdfa07fff irq 16 at device 0.0 on pci5
ix2: Using MSIX interrupts with 9 vectors
ix2: Ethernet address: 0c:c4:7a:cb:ac:78
ix2: PCI Express Bus: Speed 8.0GT/s Width x4
ix2: netmap queues/slots: TX 8/2048, RX 8/2048
ix2: promiscuous mode enabled
carp: 40@ix2: INIT -> BACKUP (initialization complete)
ix2: link state changed to UP
ifa_maintain_loopback_route: deletion failed for interface ix2: 3
ifa_maintain_loopback_route: deletion failed for interface ix2: 3
ifa_maintain_loopback_route: deletion failed for interface ix2: 3
carp: 40@ix2: BACKUP -> INIT (hardware interface up)


Auf dem Interface IX2 sind auf jedem Rechner je eine IP Adresse für das Management zugeordnet worden. Auf dem gleichen physischen Port hängt aber ebenfalls das IPMI was auch eine IP Adresse aus dem gleichen Bereich bekommen hat. Wir haben schon probiert dem IPMI ein VLAN (1) mitzugeben und es auf dem Switch mit "tagged" konfiguriert. Es hat aber nicht geholfen.

Wenn man nun beide mit einander vergleicht, kann man sehen, dass..:

Code: [Select]

ix0: link state changed to UP
ix0: promiscuous mode enabled


Code: [Select]

ix2: promiscuous mode enabled
carp: 40@ix2: INIT -> BACKUP (initialization complete)
ix2: link state changed to UP

sich die Zeilen unterscheiden. Bei Ix0 kommt zuerst Link Up und dann "promiscuous mode enabled", bei ix2 jedoch zuerst "promiscuous mode enabled" und dann "link state changed to UP". Wir wissen nicht, ob dieses Detail wichtig ist, aber das ganze sorgt halt leider dafür, dass Carp für dieses Interface nicht funktioniert. Das einzige was dann zügig hilft ist es, Carp auf z.B. dem Backup kurz zu deaktivieren und dann wieder zu aktivieren. Innerhalb von 1-2 Sekunden ist Carp dann wieder im Master-Backup.

Wir haben auch bereits zig Howtos und Parameters durchprobiert, die im Zusammenhang mit Carp stehen, aber nichts hat geholfen. Wir tippen daher aktuell auf einen Bug in OpnSense, da in unserem anderen Rechenzentrum wir das Identische Konstrukt haben, mit der Ausnahme, dass dort PfSense statt OpnSense läuft.

Hat da jemand ähnliche Probleme ?