Hohe Pingzeiten unregelmäßig auftretend
-
Hallo,
ich habe pfSense in der Version 2.6.0 auf Supermicro installiert und habe zwei Interfaces in eine Aggregation Group verbunden. Immer wieder erscheinen hohe Pingzeiten, ich verstehe aber nicht, was der Grund dafür ist.
64 bytes from 8.8.8.8: icmp_seq=4265 ttl=121 time=1.291 ms 64 bytes from 8.8.8.8: icmp_seq=4266 ttl=121 time=1.287 ms 64 bytes from 8.8.8.8: icmp_seq=4267 ttl=121 time=503.382 ms 64 bytes from 8.8.8.8: icmp_seq=4268 ttl=121 time=1.269 ms 64 bytes from 8.8.8.8: icmp_seq=4269 ttl=121 time=253.329 ms 64 bytes from 8.8.8.8: icmp_seq=4270 ttl=121 time=1.266 ms 64 bytes from 8.8.8.8: icmp_seq=4271 ttl=121 time=1.276 ms 64 bytes from 8.8.8.8: icmp_seq=4272 ttl=121 time=1.271 ms 64 bytes from 8.8.8.8: icmp_seq=4273 ttl=121 time=1.281 ms 64 bytes from 8.8.8.8: icmp_seq=4274 ttl=121 time=1.265 ms 64 bytes from 8.8.8.8: icmp_seq=4275 ttl=121 time=1.296 ms
Habe die Doku gelesen, komme aber nicht so richtig weiter (https://docs.netgate.com/pfsense/en/latest/troubleshooting/high-cpu-load.html)
Auffällig ist, dass immer wieder, wenn ein Interrupt anschlägt, die Ping nach oben geht. Wird im Monitoring auch so aufgezeichnet:
Ich habe unter den Einstellungen (System > Advanced > Network) alle Haken bei Offloading aktiviert (Hardware Checksum Offloading, Hardware TCP Segmentation Offloading, Hardware Large Receive Offloading). Leider hat dies das Verhalten nicht verbessert. Zudem habe ich die mbuf Einstellung erhöht und gerebootet, auch keine Verbesserung. Traffic Shaper habe ich keine im Einsatz.
Als Interface erkennt 'pciconf -lv' (davon sind 2 in einem lagg0 - failover):
... em0@pci0:7:0:0: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet em1@pci0:7:0:1: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet ...
Als Treiber erkennt er
igb01
.Kann mir wer einen Tipp geben, was ich falsch mache?
Vielen Dank und schöne Grüße
-
@bigbalu said in Hohe Pingzeiten unregelmäßig auftretend:
Als Treiber erkennt er igb01.
Wo siehst du das?
pciconf gibt doch em0, em1 aus und das wäre auch jener, der zur Hardware passt, soweit ich das kenne. -
@viragomann Danke für deine Rückfrage, du hast Recht, hab mich verschaut. Hier nochmal die korrekte Ausgabe für
em1:
pciconf -lv em1 em1@pci0:7:0:1: class=0x020000 card=0x10bc8086 chip=0x10bc8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB/82571GB Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet
und igb01:
pciconf -lv igb01 igb1@pci0:9:0:1: class=0x020000 card=0x10c915d9 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82576 Gigabit Network Connection' class = network subclass = ethernet
und lagg0:
ifconfig lagg0 lagg0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=81009a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,VLAN_HWFILTER> ether 00:25:90:28:96:8d inet6 fe80::225:90ff:fe28:968d%lagg0 prefixlen 64 scopeid 0xc laggproto failover lagghash l2,l3,l4 laggport: igb1 flags=5<MASTER,ACTIVE> laggport: em1 flags=0<> groups: lagg media: Ethernet autoselect status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
So sollte es richtig sein
-
@bigbalu said in Hohe Pingzeiten unregelmäßig auftretend:
Habe die Doku gelesen, komme aber nicht so richtig weiter (https://docs.netgate.com/pfsense/en/latest/troubleshooting/high-cpu-load.html)
Doofe Frage aber was hat Hohe CPU Last mit Ping Zeiten zu tun, dass du das versuchst zu troubleshooten? Von hoher CPU Load hast du nichts geschrieben? Sonst ggf. pfBlocker mal kontrolliert bzw. was konkret die hohe CPU verursacht? System Activity oder top?
Ansonsten wenn es nur die Ping Zeiten sind - Gegenstelle Switch mal angeschaut? Hat der ein Log, kann man da was rauslesen etc.? Das ist schließlich ein LAGG - wenn da ein Problem mit dem LAGG oder LACP besteht, dann sind immer 2 dran beteiligt, nicht nur die Sense.
Cheers
-
Hast du mal unter System Patches geschaut, da gab es auch einen der hohe Antwortzeiten bei großen Regelwerken behoben hat, also hier auch mal reinschauen und die angebotenen installieren.
-
@bigbalu eigentlich wurde alles gefragt, aber:
- bitte mal einen grafischen netzwerkplan (keine ahnung was du da noch so im schatten laufen hast)
- was für eine cpu hast du auf dem board (oder welche hardware genau setzt du ein)?
- hast du irgendwelche extra dienste auf der sense am laufen?
-
Erstmal vielen Dank für eure Antworten!
@JeGr Der Artikel beschreibt ja auch - sofern ich das richtig verstanden habe - wenn Pakete nicht durchkommen bzw. wenn es Probleme bei einer hohen Zahl an Paketen zu Interrupts kommt. Deswegen hab ich verschiedene Ansätze aus dem Artikel versucht, um das Verhalten der Firewall zu verbessern.
Generell habe ich keine zu hohe Last. Habe das auch geprüft, habe alle Dienste soweit möglich deaktiviert (z. B. suricata, pfblocker, usw).
Gute Idee, auf dem Switch hab ich geschaut. Der zeigt keine Errors an auf dem jeweiligen Interface. Auch im Log steht nix brauchbares drin (Logs gehen, ist ein Aruba Switch). LAGG ist auf Failover konfiguriert, auf dem Switch ist kein LACP konfiguriert.
@NOCling Danke für den Hinweis, hatte ich nicht. Habe das nachgeholt und ich glaube nicht, dass das unser Problem behebt, da meine Regelwerke relativ übersichtlich ist.
@micneu Hier mein Netzwerkplan. Ich habe zwei Switches zu einem Stack verbunden und mit VLAN ausgestattet. VLAN1 geht mit einem Kabel richtung Internetprovider und VLAN2 ist mein internes Netz:
CPU Modell: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Serverboard: Supermicro X8DT3 (Die Produktbezeichnung weiß ich leider nicht)Extra Dienste (bis auf FRR und Wireguard) hatte ich alle deinstalliert. Aktuell sind als Pakete vorhanden:
- Suricata
- Bandwithd
- ntopng
- pfBlockerNG
- Wireguard
Generell habe ich auch noch gesucht, ob auf dem Switch ein Trunk erstellt werden muss für das lagg (failover). Lt Doku von FreeBSD ist das als LACP aufgelistet, von Blogeinträgen ist dies nicht notwendig. Werde heute Abend mal Interfaces auf dem Switch deaktivieren und prüfen, ob es eine Verbesserung bringt.
Danke für eure Hilfe :)
-
Wo genau ist der LAGG in der Zeichnung konfiguriert?
-
@nocling Oh sorry. Hier das Update:
Auf den Switchen wurde wie bereits geschrieben nichts konfiguriert