33
Dropped Packets
Hallo,
ich jage gerade einem Netzwerkproblem hinterher und bin dabei auf ein Indiz gestoßen was mich eventuell zu meinem Ziel/Behebung führen könnte. Bin mir aber nicht 100% sicher ob meine Annahme stimmt. Alles fing damit das ich bei erhöhter Last mitten am Tag an meinem pfSense-Router einen großen Paketloss auf dem physischen Interface verzeichnete. In der Größenordnung 38 Pakete pro Sekunde für circa 2 Minuten.
Danach war am Abend noch ein kleinerer Fall, aber kein Vergleich. Jetzt lasse ich mir per SNMP-Traps regelmäßig rausschreiben wann Paketverluste, Paketfehler oder Packets Drops passieren. Da fiel nun auf das da einige Pakete einfach verworfen werden am Core-Switch und zwar auf der Tx- Seite.
Am Core offenbart es sich so:
Mal als Beispiel nehmen ich mal 1/1/7 (Cisco SG300 mit 1x1Gbit LWL) wo es scheinbar überhaupt keine Probleme gibt:
Und dann mal zum Vergleich der 1/1/9 (Cisco SG200 mit 1x1Gbit LWL) wo vermehrt Pakete gedroppt werden:
Bei beiden ist die Auslastung im unteren einstelligen Prozentbereich gewesen im Moment als beim letzten Mal Pakete gedroppt wurden.
So sieht es auf dem genannten SG200 aus:
Wie man sieht kein Drop Event verzeichnet.
Bei Tx Discards würde ja, so mein Verständnis, bedeuten das der Buffer des Senders voll läuft und daraufhin Pakete verworfen werden. Was sich mir nicht erschließt, da es sich hier um einen ICX7750 handelt und die Auslastung nachweißlich ein Witz ist.
Kann es sein das entweder die Module mitterlweile eine Macke haben, als eventuell die Optiken "erblinden" oder es eine anderweitige physische Beschädigung gibt? Oder sind die Werte in einem "Normbereich" und es hat eventuell völlig andere Ursachen?
Gruß
ich jage gerade einem Netzwerkproblem hinterher und bin dabei auf ein Indiz gestoßen was mich eventuell zu meinem Ziel/Behebung führen könnte. Bin mir aber nicht 100% sicher ob meine Annahme stimmt. Alles fing damit das ich bei erhöhter Last mitten am Tag an meinem pfSense-Router einen großen Paketloss auf dem physischen Interface verzeichnete. In der Größenordnung 38 Pakete pro Sekunde für circa 2 Minuten.
Danach war am Abend noch ein kleinerer Fall, aber kein Vergleich. Jetzt lasse ich mir per SNMP-Traps regelmäßig rausschreiben wann Paketverluste, Paketfehler oder Packets Drops passieren. Da fiel nun auf das da einige Pakete einfach verworfen werden am Core-Switch und zwar auf der Tx- Seite.
Am Core offenbart es sich so:
SSH@ICX7750-48F Switch#sh tech-support packet-loss
==========================================================================
BEGIN : show tech-support packet-loss
CONTEXT : SSH#1 : PP total Tx stats
TIME STAMP : 10:00:42.429 CET Fri Sep 30 2022
HW/SW INFO : ICX7750-48F/SWS08090k
==========================================================================
PP total stats :
Packet drop count due to congestion per egress port
Port lg1: Tx packets 2708863147 Dropped packets 0
Port lg4: Tx packets 169259291 Dropped packets 0
Port lg5: Tx packets 194201942 Dropped packets 16763
Port 1/1/4: Tx packets 670659303 Dropped packets 7948
Port 1/1/5: Tx packets 915107079 Dropped packets 282474
Port 1/1/6: Tx packets 524308518 Dropped packets 12779
Port 1/1/7: Tx packets 184875665 Dropped packets 0
Port 1/1/8: Tx packets 681823035 Dropped packets 152576
Port 1/1/9: Tx packets 224963445 Dropped packets 87766
Port lg2: Tx packets 1571499410 Dropped packets 0
Port lg3: Tx packets 46212909 Dropped packets 587
Port 1/2/1: Tx packets 1360612164 Dropped packets 0
Port 1/2/4: Tx packets 65043504 Dropped packets 0
Port lg4: Tx packets 138342842 Dropped packets 0
Port lg5: Tx packets 101386488 Dropped packets 1526
Port lg2: Tx packets 1092119426 Dropped packets 0
Port lg3: Tx packets 73080814 Dropped packets 157
Port 2/2/1: Tx packets 1454957721 Dropped packets 0
Port 2/2/4: Tx packets 21014682 Dropped packets 0
==========================================================================
TIME STAMP : 10:00:42.447 CET Fri Sep 30 2022
END : show tech-support packet-loss
TIME TAKEN : 424137 ticks (17813754 nsec)
==========================================================================
==========================================================================
BEGIN : show statistics brief
CONTEXT : SSH#1 : PACKET COUNTERS
TIME STAMP : 10:00:42.486 CET Fri Sep 30 2022
HW/SW INFO : ICX7750-48F/SWS08090k
==========================================================================Mal als Beispiel nehmen ich mal 1/1/7 (Cisco SG300 mit 1x1Gbit LWL) wo es scheinbar überhaupt keine Probleme gibt:
UC Egress queues:
Queue counters Queued packets Dropped Packets
0 94386374 0
1 1126708 0
2 16230461 0
3 977264 0
4 1555240 0
5 852532 0
6 10875 0
7 1937421 0
MC Egress queues:
Queue counters Queued packets Dropped Packets
0 42995614 0
1 6364004 0
2 1871510 0
3 591089 0
4 16013428 0Und dann mal zum Vergleich der 1/1/9 (Cisco SG200 mit 1x1Gbit LWL) wo vermehrt Pakete gedroppt werden:
UC Egress queues:
Queue counters Queued packets Dropped Packets
0 132858958 87766
1 10692060 0
2 1531949 0
3 698104 0
4 4607547 0
5 4564757 0
6 12193 0
7 1937703 0
MC Egress queues:
Queue counters Queued packets Dropped Packets
0 44078894 0
1 6602589 0
2 837886 0
3 591127 0
4 16013726 0Bei beiden ist die Auslastung im unteren einstelligen Prozentbereich gewesen im Moment als beim letzten Mal Pakete gedroppt wurden.
So sieht es auf dem genannten SG200 aus:
Wie man sieht kein Drop Event verzeichnet.
Bei Tx Discards würde ja, so mein Verständnis, bedeuten das der Buffer des Senders voll läuft und daraufhin Pakete verworfen werden. Was sich mir nicht erschließt, da es sich hier um einen ICX7750 handelt und die Auslastung nachweißlich ein Witz ist.
Kann es sein das entweder die Module mitterlweile eine Macke haben, als eventuell die Optiken "erblinden" oder es eine anderweitige physische Beschädigung gibt? Oder sind die Werte in einem "Normbereich" und es hat eventuell völlig andere Ursachen?
Gruß
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-Key: 4108715824
Url: https://administrator.de/contentid/4108715824
Ausgedruckt am: 25.04.2024 um 10:04 Uhr
33 Kommentare
Neuester Kommentar
Beide Switches sind Store and Forward Switches. Sprich sie würden fehlformatierte oder ungültige Pakete nicht über ihr Backbone weitergeben. Die Errors beschränken sich also immer auf den Punkt zu Punkt Link, was bedeutet das es entscheidend ist WAS an den betroffenen Ports angeschlossen ist mit welchem Traffic Profil. Andere Switches, Endgeräte wie PCs, Server oder Drucker usw.
Grundsätzlich gilt das 1-2,5% von Paket Losses bezogen auf die Gesamtlast an dem Port bei Ethernet tolerabel sind. Bei Durchschnittslasten im unteren einstelligen Bereich sollten, wie du schon richtig sagst, normalerweise keine bis marginale Losses auftreten und die Counter eher 0 zeigen.
Was du meist nicht siehst sind kurzfristige Bursts die die Last auf 70% oder mehr an einem Port hochbringen und dann im Überlastfall auch höhere Drops verursachen können in kurzen Zeiträumen die unter deinem Polling Intervall liegen.
Da ist man dann wieder bei dem Thema was ist dort angeschlossen und ob das Endgerät solche Bursts generieren kann.
Außer Lastproblematiken gibt es noch andere Gründe
Formatfehler resultieren meist daraus wenn reine Access Ports eingehend .1q Pakete bekommen die sie droppen oder wenn dort Fabric Traffic wie TRILL oder SPB Frames eingehen die nicht Ethernet konform sind. Alles zeigt dann auf Konfig Fehler. Meist sind es .1q Frames die an reinen Access Ports landen.
Es gibt also deutlich mehr Gründe als nur Congestion oder Last auf die du achten musst.
Grundsätzlich gilt das 1-2,5% von Paket Losses bezogen auf die Gesamtlast an dem Port bei Ethernet tolerabel sind. Bei Durchschnittslasten im unteren einstelligen Bereich sollten, wie du schon richtig sagst, normalerweise keine bis marginale Losses auftreten und die Counter eher 0 zeigen.
Was du meist nicht siehst sind kurzfristige Bursts die die Last auf 70% oder mehr an einem Port hochbringen und dann im Überlastfall auch höhere Drops verursachen können in kurzen Zeiträumen die unter deinem Polling Intervall liegen.
Da ist man dann wieder bei dem Thema was ist dort angeschlossen und ob das Endgerät solche Bursts generieren kann.
Außer Lastproblematiken gibt es noch andere Gründe
- Kaputte Checksummen oder Header Checksummen
- Kaputte Frame Check Sequence
- Runt oder Giant Pakets (Formatfehler)
- Hardware oder Software Fehler und Bugs
- DoS Attacken
Formatfehler resultieren meist daraus wenn reine Access Ports eingehend .1q Pakete bekommen die sie droppen oder wenn dort Fabric Traffic wie TRILL oder SPB Frames eingehen die nicht Ethernet konform sind. Alles zeigt dann auf Konfig Fehler. Meist sind es .1q Frames die an reinen Access Ports landen.
Es gibt also deutlich mehr Gründe als nur Congestion oder Last auf die du achten musst.
Also an dem besagten Core-Switch ICX7750 sind Switche angeschlossen und ein pfSense-Router. Die Switche sind fast alle aus dem Hause Cisco (SG200, SG300 und SG350X) mit einer Ausnahme (ICX7250), einige auch schon etwas betagt, aber alle auf letzten verfügbaren stable Firmware-Stand.
Laut diesem Dokument:
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...
Läuft der ICX7750 bei 10Gbit-Verbindungen im Default im Cut-Through. Nur 1Gbit-Anbindungen sind Store-and-Forward. Allerdings würde sich, wenn ich es richtig verstanden habe, ein Fehler mit Cut-Through in einem FCS Error münden. Dieses widerum müsste in der Port Statistik auftauchen. Da sind aber keine Fehler aufgeführt.
Aber wenn ich mir das so überlege und das mir so durchlese was du schreibst, könnte tatsächlich meine PHY an der pfSense (10Gbit LWL) einen Treffer haben. Ich werde dort mal die Schnittstellen tauschen und weiter beobachten.
Formatfehler in Richtung Trill oder SPB kann ich mir nicht vorstellen, da soetwas in dieser Umgebung nicht eingesetzt wird. Wüsste jetzt auch nicht wo sowas herkommen sollte. Für einen DDOS ist mir die Alltime-Utilization zu niedrig und eher konstant.
Bei defekten Checksummen, denke ich widerum an ein Problem bei der pfSense. Komisch ist halt das manche Switch-Switch-Verbindungen offenbar gar nicht betroffen sind, aber es lässt sich da auch nicht unbedingt ein Muster erkennen. Während bei z.B. einen SG300 mit identischen Optiken und Config vermehrt Drops verzeichnet werden, hat ein anderer genau NULL (0).
Laut diesem Dokument:
https://docs.commscope.com/bundle/fastiron-08095-managementguide/page/GU ...
Läuft der ICX7750 bei 10Gbit-Verbindungen im Default im Cut-Through. Nur 1Gbit-Anbindungen sind Store-and-Forward. Allerdings würde sich, wenn ich es richtig verstanden habe, ein Fehler mit Cut-Through in einem FCS Error münden. Dieses widerum müsste in der Port Statistik auftauchen. Da sind aber keine Fehler aufgeführt.
Aber wenn ich mir das so überlege und das mir so durchlese was du schreibst, könnte tatsächlich meine PHY an der pfSense (10Gbit LWL) einen Treffer haben. Ich werde dort mal die Schnittstellen tauschen und weiter beobachten.
Formatfehler in Richtung Trill oder SPB kann ich mir nicht vorstellen, da soetwas in dieser Umgebung nicht eingesetzt wird. Wüsste jetzt auch nicht wo sowas herkommen sollte. Für einen DDOS ist mir die Alltime-Utilization zu niedrig und eher konstant.
Bei defekten Checksummen, denke ich widerum an ein Problem bei der pfSense. Komisch ist halt das manche Switch-Switch-Verbindungen offenbar gar nicht betroffen sind, aber es lässt sich da auch nicht unbedingt ein Muster erkennen. Während bei z.B. einen SG300 mit identischen Optiken und Config vermehrt Drops verzeichnet werden, hat ein anderer genau NULL (0).
Hier mal die Statistik von 1/1/9 auf dem öfters Mal Pakete gedroppt werden:
Nicht mal CRC-Fehler oder irgendwas. Jetzt kann es natürlich sein das die Overall-Auslastung zwar niedrig ist, aber die Peaks ziemlich heftig dafür, womit natürlich die Discards in einem Bereich außerhalb der akzeptablen Marke (1-2%) landen. Die Frage ist, wie geht man da eine Behebung an?
Durchsatz erhöhen in Form von LAG? Oder höhrere Bandbreiten?
Ich habe natürlich immer mal wieder Peaks im Netz, mal als Beispiel:
Das liegt aber eher daran das hier manchmal große Datenmengen von A nach B verschoben werden, da gerade auch über Tag verschiedene Backup Syncs auf redundante Systeme geschoben werden.
Port 1/1/9 Counters:
InOctets 30089763336 OutOctets 141802996746
InPkts 115018742 OutPkts 226161597
InBroadcastPkts 306912 OutBroadcastPkts 9150368
InMulticastPkts 2598289 OutMulticastPkts 61059736
InUnicastPkts 112113541 OutUnicastPkts 155951493
InBadPkts 0
InFragments 0
InDiscards 0 OutErrors 0
CRC 0 Collisions 0
InErrors 0 LateCollisions 0
InGiantPkts 0
InShortPkts 0
InJabber 0 OutDiscards 87766
InFlowCtrlPkts 0 OutFlowCtrlPkts 0
InBitsPerSec 28488 OutBitsPerSec 82680
InPktsPerSec 17 OutPktsPerSec 35
InUtilization 0.00% OutUtilization 0.00%Nicht mal CRC-Fehler oder irgendwas. Jetzt kann es natürlich sein das die Overall-Auslastung zwar niedrig ist, aber die Peaks ziemlich heftig dafür, womit natürlich die Discards in einem Bereich außerhalb der akzeptablen Marke (1-2%) landen. Die Frage ist, wie geht man da eine Behebung an?
Durchsatz erhöhen in Form von LAG? Oder höhrere Bandbreiten?
Ich habe natürlich immer mal wieder Peaks im Netz, mal als Beispiel:
Das liegt aber eher daran das hier manchmal große Datenmengen von A nach B verschoben werden, da gerade auch über Tag verschiedene Backup Syncs auf redundante Systeme geschoben werden.
Wenn die Lastspitzen immer zu gleichen Zeiten auftreten kannst du das ja einfach testen indem du die Statistik Counter mit clear count danach löschst. Bleiben sie bis zur nächsten Spitze auf 0 und gehen nach der Lastspitze wieder hoch ist es ein Last/Congestion Problem.
Kann aber auch Staub usw. sein wie man hier sehr schön sehen kann.
PfSense RX Error auf WAN
an dem besagten Core-Switch ICX7750 sind Switche angeschlossen
Hast du den oder die auf Single Span umgestellt, denn die SGs können kein PVST was die ICXe per Default machen?!ICX7750 bei 10Gbit-Verbindungen im Default im Cut-Through
OK, 7750 hatte ich überlesen, der ja. Verwechselt mit 7150, 7250, sorry. Der gibt dann aber Errors weiter aber eben rein nur auf den 10G Ports. Da wird Troubleshooting dann etwas mehr tricky.Ich werde dort mal die Schnittstellen tauschen und weiter beobachten
Wäre ein erster Ansatz. SFPs kosten ja nix mehr und du hast sicher noch Spare in der Schublade. Das sie blind werden ist bei MM, 50µ Optiken eher selten es sei denn man hat sehr kurze Kabel. Bei SM, 9µ Optiken ist das aber ein ernstes Thema wenn man dort kurze Längen hat. Da sollte man dann dämpfen oder die Kabel zumindestens eng aufrollen zur Dämpfung.Kann aber auch Staub usw. sein wie man hier sehr schön sehen kann.
Formatfehler kann ich mir nicht vorstellen
Wie gesagt, das kann auch sein wenn eine Seite Access ist und die andere .1q aber das PVID VLAN passt dann mit dem Access. Vermeintlich geht alles aber die .1q Seite sendet Tags was dann zu einseitigen Drops auf der Access Seite führt. Meist Flüchtigkeitsfehler bei der Konfig.Bei defekten Checksummen, denke ich widerum an ein Problem bei der pfSense
War da nicht mal irgendwas mit EEE Paketen...?!PfSense RX Error auf WAN
Gute Idee, da werde ich mich mal auf die Lauer legen.
Ja, Single Span ist gesetzt:
Zur Not kann ich bei meiner Sense auch auf 10Gbit per Kupfer wechseln. Ich weiß, nicht gerade toll, aber zum Abklären sollte das gehen.
Das EEE ist deaktiviert, obwohl ich bei der pfSense mir seit jeher nicht sicher bin ob es das wirklich ist. Der Treiber der NIC sagt, ist deaktiviert. Aber das hat sich auch nicht in dieser Form geäußert. Bei EEE waren es über den Tag verteilt immer mal wieder kleinere Paketverluste, also über den Tag vielleicht 10 Pakete. Hier war es jetzt innerhalb von 2 Minuten fast 5000 und danach wieder Ruhe. Das ist schon mehr als komisch.
Ja, Single Span ist gesetzt:
!
spanning-tree single 802-1w
spanning-tree single 802-1w priority 4096
!Zur Not kann ich bei meiner Sense auch auf 10Gbit per Kupfer wechseln. Ich weiß, nicht gerade toll, aber zum Abklären sollte das gehen.
Das EEE ist deaktiviert, obwohl ich bei der pfSense mir seit jeher nicht sicher bin ob es das wirklich ist. Der Treiber der NIC sagt, ist deaktiviert. Aber das hat sich auch nicht in dieser Form geäußert. Bei EEE waren es über den Tag verteilt immer mal wieder kleinere Paketverluste, also über den Tag vielleicht 10 Pakete. Hier war es jetzt innerhalb von 2 Minuten fast 5000 und danach wieder Ruhe. Das ist schon mehr als komisch.
1
Hallo zusammen,
also seit der pfSense 2.6 werden alle Erros angezeigt und vorher eben nicht alle. Von daher sind nun einige
Benutzer verunsichert. Wobei man hier aber auch noch einmal zwischen den Fehlern und verworfenen
Paketen und den fehlerhaften Paketen unterschieden muss.
Egal was Du hier von benutzen oder umsetzen willst oder eben auch nicht, nicht gleich aufgeben!!!
Das ist das wichtigste überhaupt! Manchmal ist es oder sind es eben mehrere Punkte die man angehen
muss um das Ziel zu erreichen und viele, leider sehr viele Leute nehmen eine oder zwei Sachen in Anlauf
und sind dann sehr enttäuscht und geben auf!
Mal ein Beispiel man muss versuchen das eine Tuning mit dem anderen in Einklang zu bringen;
- NumBufferSize erhöhen und die Anzahl der Queues plus deren Länge
- Original Firmware drauf und die NumBuffSize erhöhen bzw. verkleinern plus die MTU
- 10 GBit/s NICs von Broadcom von oben nach unten (BufferSize) und Intel von unten nach oben versuchen
Bei Broadcom ist da machen es die 30.000 ButterSize und bei Intel die 1.000.000 BufferSize (als Beispiel)
Wenn die Puffer für die NICs voll sind, dann verwirft die pfSense die noch ankommenden Pakete eben auch,
d.h. wenn dann immer noch viele Pakete hinzukommen sollten. Man kann da aber an der Größe des Puffers
noch etwas einstellen, damit das eben nicht mehr das Fall ist.
Hier ist eben mehr RAM besser weil man dann eben mehr Speicher für Anzahl und Größe des Puffers,
für mehr und längere Queues zuweisen kann. Ist dann noch Snort, Squid und pfBlocker-NG mit im
Spiel wenn auch nur Teilweise, kann man auch dort mehr Speicher zuweisen bzw. mit mehr Speicher
kann es nicht zu einem Engpass kommen. Squid Cache RAM, Snort Rules update RAMDisk, ClamAV
riles (Signatures). Hat man eine oder mehrere HDD/SSDs dann wäre da noch die Swap Partition zu
nennen und die kann man pro HDD/SSD auf 4 GB setzen, wenn dann der RAM einmal eng wird,
wird eben ausgelagert und es stört Niemanden ob da 2 GB voll sind oder nicht, aber es hilft dem
System wenn etwas ausgelagert werden muss. Wann laufen denn die Updates dazu bei Dir?
Die Queues und zwar deren Länge und deren Größe sind dann noch zu erwähnen, die kann man auch etwas
vergrößern oder eben verkleinern, das kann dann auch noch einmal zu einer Durchsatz- oder Geschwindigkeitssteigerung beitragen, bzw. dass der gesamte Network-Flow etwas harmonischer verläuft.
pfSense Hardware Tuning and Troubleshooting
dann könnte man auch einmal darüber nachdenken, die original Firmware drauf zu "flashen", das schafft auch
recht oft bei Problemen Abhilfe. Also bei Intel Karten dann die original Intel Firmware, als Beispiel. Auch eine
aktualisierte Firmware kann es sein oder den Erfolg bringen.
Bei kopieren von großen und kleinen Dateien, kann mal die MTU an allen beteiligten Geräten überprüfen
ob die auch alle gleich groß eingestellt sind bzw. dann eben so einstellen.
Missing link route for a local target
Netzwerkdesign
LWL Optiken reinigen
NEOCLEAN-E LC/MU 1,25mm One-Push Reinigungsstift, 750+ Reinigungsvorgänge
Wenn Du den nicht schon hast
LWL Leitung nachmessen:
FOPM-202 Optischer Hand-Leistungsmesser (-50~+26dBm) mit 2,5mm FC/SC/ST-Anschluss FOPM-202 Optischer Hand-Leistungsmesser (-50~+26dBm) mit 2,5mm FC/SC/ST-Anschluss
Sind auch für andere Anschlüsse als SC/ST Verfügbar
Dobby
also seit der pfSense 2.6 werden alle Erros angezeigt und vorher eben nicht alle. Von daher sind nun einige
Benutzer verunsichert. Wobei man hier aber auch noch einmal zwischen den Fehlern und verworfenen
Paketen und den fehlerhaften Paketen unterschieden muss.
Egal was Du hier von benutzen oder umsetzen willst oder eben auch nicht, nicht gleich aufgeben!!!
Das ist das wichtigste überhaupt! Manchmal ist es oder sind es eben mehrere Punkte die man angehen
muss um das Ziel zu erreichen und viele, leider sehr viele Leute nehmen eine oder zwei Sachen in Anlauf
und sind dann sehr enttäuscht und geben auf!
Mal ein Beispiel man muss versuchen das eine Tuning mit dem anderen in Einklang zu bringen;
- NumBufferSize erhöhen und die Anzahl der Queues plus deren Länge
- Original Firmware drauf und die NumBuffSize erhöhen bzw. verkleinern plus die MTU
- 10 GBit/s NICs von Broadcom von oben nach unten (BufferSize) und Intel von unten nach oben versuchen
Bei Broadcom ist da machen es die 30.000 ButterSize und bei Intel die 1.000.000 BufferSize (als Beispiel)
Wenn die Puffer für die NICs voll sind, dann verwirft die pfSense die noch ankommenden Pakete eben auch,
d.h. wenn dann immer noch viele Pakete hinzukommen sollten. Man kann da aber an der Größe des Puffers
noch etwas einstellen, damit das eben nicht mehr das Fall ist.
Hier ist eben mehr RAM besser weil man dann eben mehr Speicher für Anzahl und Größe des Puffers,
für mehr und längere Queues zuweisen kann. Ist dann noch Snort, Squid und pfBlocker-NG mit im
Spiel wenn auch nur Teilweise, kann man auch dort mehr Speicher zuweisen bzw. mit mehr Speicher
kann es nicht zu einem Engpass kommen. Squid Cache RAM, Snort Rules update RAMDisk, ClamAV
riles (Signatures). Hat man eine oder mehrere HDD/SSDs dann wäre da noch die Swap Partition zu
nennen und die kann man pro HDD/SSD auf 4 GB setzen, wenn dann der RAM einmal eng wird,
wird eben ausgelagert und es stört Niemanden ob da 2 GB voll sind oder nicht, aber es hilft dem
System wenn etwas ausgelagert werden muss. Wann laufen denn die Updates dazu bei Dir?
Die Queues und zwar deren Länge und deren Größe sind dann noch zu erwähnen, die kann man auch etwas
vergrößern oder eben verkleinern, das kann dann auch noch einmal zu einer Durchsatz- oder Geschwindigkeitssteigerung beitragen, bzw. dass der gesamte Network-Flow etwas harmonischer verläuft.
pfSense Hardware Tuning and Troubleshooting
- NIC Hersteller und Modell herausfinden
- Den installierten Treiber ausfindig machen
- Die dazugehörigen Tuneables dazu anschauen.
Aber wenn ich mir das so überlege und das mir so durchlese was du schreibst, könnte tatsächlich meine
PHY an der pfSense (10Gbit LWL) einen Treffer haben. Ich werde dort mal die Schnittstellen tauschen
und weiter beobachten.
Wenn das Netzwerkkarten (NICs) sind, die eventuell gebraucht gekauft wurden, also von HP, Dell oder FujitsuPHY an der pfSense (10Gbit LWL) einen Treffer haben. Ich werde dort mal die Schnittstellen tauschen
und weiter beobachten.
dann könnte man auch einmal darüber nachdenken, die original Firmware drauf zu "flashen", das schafft auch
recht oft bei Problemen Abhilfe. Also bei Intel Karten dann die original Intel Firmware, als Beispiel. Auch eine
aktualisierte Firmware kann es sein oder den Erfolg bringen.
Bei kopieren von großen und kleinen Dateien, kann mal die MTU an allen beteiligten Geräten überprüfen
ob die auch alle gleich groß eingestellt sind bzw. dann eben so einstellen.
- Kein Route zum Target Network oder keine default route
Missing link route for a local target
- Veralteter Pfad oder Angabe zu/bei einer Regel
- NIC Buffer sind voll (zu klein)
Netzwerkdesign
- Wären nicht zwei oder mehr Routingpunkte im Netzwerk besser?
- Muss bei einem Backup oder Kopiervorgang immer alles voll durch die Firewall laufen?
LWL Optiken reinigen
NEOCLEAN-E LC/MU 1,25mm One-Push Reinigungsstift, 750+ Reinigungsvorgänge
Wenn Du den nicht schon hast
LWL Leitung nachmessen:
FOPM-202 Optischer Hand-Leistungsmesser (-50~+26dBm) mit 2,5mm FC/SC/ST-Anschluss FOPM-202 Optischer Hand-Leistungsmesser (-50~+26dBm) mit 2,5mm FC/SC/ST-Anschluss
Sind auch für andere Anschlüsse als SC/ST Verfügbar
Dobby
1
Also ich habe das Tuning eigentlich schon alles durch. Meist hat nicht wirklich spürbar etwas verändert. Ich habe die Intel "ix". Da steht folgendes bei mir in der loader.conf:
Das habe ich jetzt mal mit dazu genommen:
Meine Maschine ist eigentlich schon ziemlich potent ausgestattet. Intel Xeon mit 8 Kernen, 32Gb RAM, SSD. Verbaut sind onboard Intel IX Chips also Intel 700. Zwei Mal als SFP-Slot und zwei Mal 10Gbit RJ45 ausgeführt. pFBlocker ist aktiv. Ein paar IPSec-Verbindungen, FRR mit BGP, ein paar OVPN. RAM-Auslastung ist selten bei mehr als 10%.
MBUF Usage zeigt gegenwärtig 2% (20878/1000000). Komisch ist halt das das die Discards immer an den Schnittstelle zu den Etagenverteiler-Switchen zunehmen und nicht an der pfSense selbst.
IP Input Queue Drops habe ich überprüft, steht auf 0. Also wird nichts verworfen.
Generell steigen die Discards sobald auf einer Schnittstelle Last ist. Beispiel: Ich habe hier einen Backup-Server auf den ein Sync eines anderen Backup-Server läuft. Beide befinden sich im selben VLAN, der Transfer findet also nicht über die pfSense statt. Aber dennoch steigt beim Sync die Discard-Rate teilweise auf über 9%.
Das kann doch nicht normal sein, oder?
Der Weg gestaltet sich so:
Routing über die Switche scheue ich etwas, weil ich mit der pfSense mehr Übersicht und teilweise schon recht komplizierte Sachen umgesetzt habe. Ich filtere z.B. massiv zwischen den VLANs. Wenn ich das alles über die CLI umsetzen soll, dann wirds lustig.
kern.ipc.nmbclusters="1000000"
kern.ipc.nmbjumbop="524288" Das habe ich jetzt mal mit dazu genommen:
hw.intr_storm_threshold="10000" Meine Maschine ist eigentlich schon ziemlich potent ausgestattet. Intel Xeon mit 8 Kernen, 32Gb RAM, SSD. Verbaut sind onboard Intel IX Chips also Intel 700. Zwei Mal als SFP-Slot und zwei Mal 10Gbit RJ45 ausgeführt. pFBlocker ist aktiv. Ein paar IPSec-Verbindungen, FRR mit BGP, ein paar OVPN. RAM-Auslastung ist selten bei mehr als 10%.
MBUF Usage zeigt gegenwärtig 2% (20878/1000000). Komisch ist halt das das die Discards immer an den Schnittstelle zu den Etagenverteiler-Switchen zunehmen und nicht an der pfSense selbst.
IP Input Queue Drops habe ich überprüft, steht auf 0. Also wird nichts verworfen.
Generell steigen die Discards sobald auf einer Schnittstelle Last ist. Beispiel: Ich habe hier einen Backup-Server auf den ein Sync eines anderen Backup-Server läuft. Beide befinden sich im selben VLAN, der Transfer findet also nicht über die pfSense statt. Aber dennoch steigt beim Sync die Discard-Rate teilweise auf über 9%.
Das kann doch nicht normal sein, oder?
Der Weg gestaltet sich so:
Routing über die Switche scheue ich etwas, weil ich mit der pfSense mehr Übersicht und teilweise schon recht komplizierte Sachen umgesetzt habe. Ich filtere z.B. massiv zwischen den VLANs. Wenn ich das alles über die CLI umsetzen soll, dann wirds lustig.
Beide befinden sich im selben VLAN, der Transfer findet also nicht über die pfSense statt.
- Sind die beiden Sync Hosts Backup 1 und 2 ? Transfer geht also via ToR-CoreSW-Etage.
- Zeigen beide bzw. alle beteiligten Ports im gesamten Pfad der Sync Partner dieselben Discard Raten?
- Welches Images nutzt du auf den beteiligten Switches?
Zitat von @aqui:
Genau. Von Backup 1 auf Backup 2. Ebenfalls richtig.Beide befinden sich im selben VLAN, der Transfer findet also nicht über die pfSense statt.
* Sind die beiden Sync Hosts Backup 1 und 2 ? Transfer geht also via ToR-CoreSW-Etage.* Zeigen beide bzw. alle beteiligten Ports im gesamten Pfad der Sync Partner dieselben Discard Raten?
Nein. Der Backup 1 bleibt sehr konstant unter bei 0,65%. Während der Backup 2 dann auf mal 4%, dann auch mal bei 9% landet. Komischerweise meldet sich aber in dieser Zeit kein Switch mit DIscard-Problemen.* Welches Images nutzt du auf den beteiligten Switches?
ToR ICX7250 => SPS08090h (UFI)
Core ICX7750 => SWS08090k (UFI)
Cisco SG200 => 1.4.11.5
Sorry im Bild oben habe ich Blödsinn geschrieben, das ist ein SG200-26P und kein SG300.
Recommended ist die 8.0.95 mit dem aktuellsten Patchrelease. Nicht das das ursächlich ist aber unter die 8.0.95 solltest du nicht mehr gehen!
Es wäre generell hilfreich wenn alle beteiligten Komponenten die latest und greatest hätten.
Auffällig ist das die Discards verstärkt am SoHo Switch auftreten.
Was bei den SoHos öfter mal passiert ist ein MDI-X Mismatch was dann in höhere Collision Rates resultiert bei steigender Last. Würde also ggf. einmal Sinn machen die Speed und Duplex Parameter an Backup 2 testweise einmal auf statische Werte zu setzen.
Congestion Probleme und Überlauf Probleme der Port RX und TX Queues am SG200 kann es ja eigentlich nicht geben da die Rate von Backup 1 identisch ist.
Problematisch ist das nur dann, wenn in solchen Sync Momenten noch anderer Traffic an Backup 2 kumuliert. SoHo Switches haben deutlich kleinere Port Buffer als deine Premium Switches. Sind die überlastet werden Pakets dort schlicht und einfach gedroppt und deine Counter gehen hoch. Es ist also auch etwas eine Frage der Voluminas an Backup 2.
Hast du ggf. einen Spare ICX den du mal testweise gegen den SG tauschen kannst?
Es wäre generell hilfreich wenn alle beteiligten Komponenten die latest und greatest hätten.
Auffällig ist das die Discards verstärkt am SoHo Switch auftreten.
Was bei den SoHos öfter mal passiert ist ein MDI-X Mismatch was dann in höhere Collision Rates resultiert bei steigender Last. Würde also ggf. einmal Sinn machen die Speed und Duplex Parameter an Backup 2 testweise einmal auf statische Werte zu setzen.
Congestion Probleme und Überlauf Probleme der Port RX und TX Queues am SG200 kann es ja eigentlich nicht geben da die Rate von Backup 1 identisch ist.
Problematisch ist das nur dann, wenn in solchen Sync Momenten noch anderer Traffic an Backup 2 kumuliert. SoHo Switches haben deutlich kleinere Port Buffer als deine Premium Switches. Sind die überlastet werden Pakets dort schlicht und einfach gedroppt und deine Counter gehen hoch. Es ist also auch etwas eine Frage der Voluminas an Backup 2.
Hast du ggf. einen Spare ICX den du mal testweise gegen den SG tauschen kannst?
Das war schonmal meine Überlegung gewesen, alle SMB-Switches heraus zu schmeißen. Aber da die Verfügbarkeit von brauchbaren Gerät immer noch grottig ist. Habe ich es weiter hinaus gezögert. Die Teile sind jetzt teilweise 5 Jahre alt, was ansich kein Alter ist, aber da gab in der Zwischenzeit schon wieder Switche mit besserer Ausstattung Performance.
Den pauschalen Tausch könnte ich an anderer Stelle vollziehen, da ich gerade keinen PoE-fähigen Premium-Switch zu Verfügung habe:
Ich habe hier einen weiteren Switch, wo ich nicht verstehen kann warum dort so häufig Discards auftreten und mir nicht verständlich ist warum: Es handelt sich um einen SG200-50, auf dem Switch ist die Auslastung eigentlich nicht weltbewegend oder nicht der Rede wert. Aber dennoch immer wieder Discards zwischen von 1,7% bis 4,5%. Obwohl da bis auf ein Rechner für Dokumenten-Scans (großer Dokuscanner scannt Dokumente in eine SMB-Freigabe) nichts außergewöhnliches dranhängt. Der Rest sind Clients, die normale Office-Arbeiten machen und im Internet surfen.
Hier meldet auch nur der ICX7750 Core am Uplink-Port die Discards, aber der SG200-50 selbst nicht. Ich kann diesen gegen einen ICX7250 tauschen.
Den pauschalen Tausch könnte ich an anderer Stelle vollziehen, da ich gerade keinen PoE-fähigen Premium-Switch zu Verfügung habe:
Ich habe hier einen weiteren Switch, wo ich nicht verstehen kann warum dort so häufig Discards auftreten und mir nicht verständlich ist warum: Es handelt sich um einen SG200-50, auf dem Switch ist die Auslastung eigentlich nicht weltbewegend oder nicht der Rede wert. Aber dennoch immer wieder Discards zwischen von 1,7% bis 4,5%. Obwohl da bis auf ein Rechner für Dokumenten-Scans (großer Dokuscanner scannt Dokumente in eine SMB-Freigabe) nichts außergewöhnliches dranhängt. Der Rest sind Clients, die normale Office-Arbeiten machen und im Internet surfen.
Hier meldet auch nur der ICX7750 Core am Uplink-Port die Discards, aber der SG200-50 selbst nicht. Ich kann diesen gegen einen ICX7250 tauschen.
Ich konnte ein Problem ausfindig machen. An einem Port der LAG der pfSense hat es ordentlich geflappt. Nachdem ich das Modul getauscht habe, funktioniert es bisher ohne Probleme. Habe ich nur herausgefunden weil ich per System Tunables folgendes aktiv hatte:
Des weiteren scheint:
auch etwas Besserung gebracht zu haben.
Als nächstes werde ich noch Updates machen und den einen Switch pauschal tauschen.
Lohnt es sich, von Performance her, einen SG200 gegen einen Mikrotik CRS354 zu tauschen? Oder ist das eher vom "Regen in die Traufe"?
net.link.lagg.lacp.debugDes weiteren scheint:
hw.intr_storm_threshold="10000" auch etwas Besserung gebracht zu haben.
Als nächstes werde ich noch Updates machen und den einen Switch pauschal tauschen.
Lohnt es sich, von Performance her, einen SG200 gegen einen Mikrotik CRS354 zu tauschen? Oder ist das eher vom "Regen in die Traufe"?
einen SG200 gegen einen Mikrotik CRS354 zu tauschen?
Letzteres, der hat noch weniger Portbuffer. Aber Versuch macht wie immer klug! 😉
Der SG200 wurde jetzt gegen einen ICX7250 getauscht. Der ist jetzt allerdings mit 2x10Gbit als LAG angebunden. Bei dieser Konstellation treten keine Discards auf.
Das führt zu zwei Schlußfolgerungen:
Wobei man bei ersteren sagen muss, das dieser eigentlich mit dem Traffic klar kommen muss, hat immerhin auch 16Mb Packet Buffer. 1Gbit Uplink muss auch dicke reichen. Es sei den die Schnittstelle performt bei vielen kleineren Paketen schlechter, was man jetzt so pauschal nicht testen kann.
Interessant ist auch die Beobachtung, das ich nachdem ich den SG200 rausgenommen habe, bei einer anderen Leitung am Core - wo ein SG350X mit 1Gbit Uplink dran hängt - die Discars nun gestiegen sind. Keine Ahnung wie das zusammenhängt. Aber ich mutmaße mal, das sobald ich dort aufrüste auf 10Gbit mit LAG, das dann auch diese Problematik verschwunden ist. Dennoch verstehe ich die Gründe und den Sinn nicht komplett. Weil der Traffic ist im Mittel nicht weiter gestiegen.
Das führt zu zwei Schlußfolgerungen:
- Entweder macht der ICX irgendwas besser oder der SG200 etwas schlechter
- Die LAG in Verbindung mit erhöhter Bandbreite sorgt für ein besseres Handling des zugrundeliegenden Traffic
Wobei man bei ersteren sagen muss, das dieser eigentlich mit dem Traffic klar kommen muss, hat immerhin auch 16Mb Packet Buffer. 1Gbit Uplink muss auch dicke reichen. Es sei den die Schnittstelle performt bei vielen kleineren Paketen schlechter, was man jetzt so pauschal nicht testen kann.
Interessant ist auch die Beobachtung, das ich nachdem ich den SG200 rausgenommen habe, bei einer anderen Leitung am Core - wo ein SG350X mit 1Gbit Uplink dran hängt - die Discars nun gestiegen sind. Keine Ahnung wie das zusammenhängt. Aber ich mutmaße mal, das sobald ich dort aufrüste auf 10Gbit mit LAG, das dann auch diese Problematik verschwunden ist. Dennoch verstehe ich die Gründe und den Sinn nicht komplett. Weil der Traffic ist im Mittel nicht weiter gestiegen.
Das ist in der Tat interessant. Könnte aber daran liegen das der Cut Through Switch dort auch kaputte Pakets weiterreicht. Aber eigentlich müsste der neue ICX die dann auch anzeigen. Das eine (Paket Buffer) widerspricht irgendwie dem anderen (kaputte Pakets).
Der Link auf den 350X ist der mit Kupfer oder Glas realisiert?! Wenn Glas hier ggf. mal die Optik tauschen. Es gibt übrigens ein aktuelles Firmware Update für die SG3xx-X Serie die einige Fixes in dem Bereich hat!
Der Link auf den 350X ist der mit Kupfer oder Glas realisiert?! Wenn Glas hier ggf. mal die Optik tauschen. Es gibt übrigens ein aktuelles Firmware Update für die SG3xx-X Serie die einige Fixes in dem Bereich hat!
Zitat von @aqui:
Das ist in der Tat interessant. Könnte aber daran liegen das der Cut Through Switch dort auch kaputte Pakets weiterreicht. Aber eigentlich müsste der neue ICX die dann auch anzeigen. Das eine (Paket Buffer) widerspricht irgendwie dem anderen (kaputte Pakets).
Der Link auf den 350X ist der mit Kupfer oder Glas realisiert?! Wenn Glas hier ggf. mal die Optik tauschen. Es gibt übrigens ein aktuelles Firmware Update für die SG3xx-X Serie die einige Fixes in dem Bereich hat!
Das ist in der Tat interessant. Könnte aber daran liegen das der Cut Through Switch dort auch kaputte Pakets weiterreicht. Aber eigentlich müsste der neue ICX die dann auch anzeigen. Das eine (Paket Buffer) widerspricht irgendwie dem anderen (kaputte Pakets).
Der Link auf den 350X ist der mit Kupfer oder Glas realisiert?! Wenn Glas hier ggf. mal die Optik tauschen. Es gibt übrigens ein aktuelles Firmware Update für die SG3xx-X Serie die einige Fixes in dem Bereich hat!
Der Link am SG350X ist per LWL. Historisch bedingt nur 1Gbit, weil der mal getauscht wurde. Im Zuge die Optik zu tauschen, würde ich jetzt hier ebenfalls gleich auf 10Gbit LWL mit LAG gehen. Wenn schon Downtime will ich gleich komplett durchziehen.
OK, das macht Sinn. Das Ergebnis wäre dann mal spannend... 😉
Ja, aktuelle Version ist bereits 2.5.9.13.
Aber eines ist mal Fakt... dieser Cisco ### kommt mir nicht mehr ins Haus. Furchtbar. Hatte mich schon gewundert warum die WebGUI so laggy ist. Daraufhin neugestartet und jetzt lässt er keinen Login mehr zu, obwohl vorher die Config in die startup gesichert wurde. Jetzt läuft er zwar, aber ich komme nicht mehr in die Verwaltung. Das soll mal einer verstehen.
Edit: Scheinbar hat das Teil auch irgendeinen Treffer. PoE an der Karre reagiert gar nicht mehr. Irgendwas hat er nicht verkraftet.
Aber eines ist mal Fakt... dieser Cisco ### kommt mir nicht mehr ins Haus. Furchtbar. Hatte mich schon gewundert warum die WebGUI so laggy ist. Daraufhin neugestartet und jetzt lässt er keinen Login mehr zu, obwohl vorher die Config in die startup gesichert wurde. Jetzt läuft er zwar, aber ich komme nicht mehr in die Verwaltung. Das soll mal einer verstehen.
Edit: Scheinbar hat das Teil auch irgendeinen Treffer. PoE an der Karre reagiert gar nicht mehr. Irgendwas hat er nicht verkraftet.
aber ich komme nicht mehr in die Verwaltung.
Du bist zu sehr Klicki Bunti bezogen! 😉 CLI mit PuTTY per SSH oder Telnet geht immer.Das liegt aber nicht immer am Cisco sondern oft auch am Browser, da die Oberfläche Java verwendet. Achte da also drauf das du das latest und greatest dort hast. Und mal den Browsercache und den Verlauf löschen, dann klappts danach meist wieder problemlos. Die CBS Nachfolger sind da übrigens deutlich schneller.
Scheinbar hat das Teil auch irgendeinen Treffer. PoE an der Karre reagiert gar nicht mehr.
Das scheint in der Tat wohl ein Serienfehler zu sein. Das hatte ich hier schon bei 3 dieser Teile ebenso. 
Hab nie die Ursache dafür gefunden.
Bei den Small Business habe ich nie viel mit der CLI gemacht, weil das bei jeder Produktserie irgendein ein anderes OS drauf war. Bei den SG200er geht es sowieso nicht, dann gibt es wieder Unterschiede zwischen SG300 und SG350X. Bei dem einen kann man das nicht, bei einem kann man jenes nicht. Teilweise war die Syntax anders. Wenn man was einheitliches will muss man zu Catalyst oder Nexus greifen, aber das sind halt Mondpreise.
Keine Ahnung wie das bei der neuen CBS-Serie ist. Generell ist es gerade absolut erschreckend was auf dem Markt für Business Switches und Router los ist. Ich dachte, nach fast zwei Jahren Durststrecke bekommen die Hersteller mal ihre Probleme auf die Kette. Leider Fehlanzeige. Es ist durch die Bank weg nichts lieferbar oder Preise wo einem schlecht wird.
Selbst Mikrotik, die bei mir als beliebter Notnagel gelten, ist in Deutschland in den letzten Wochen quasi ausgestorben. Wenn man mehr als ein Gerät bestellen will, kann man das vergessen. Oder bei Ruckus im Juli noch für 2000€ einen 7150-48P gekauft, jetzt zahlt man 3500€. Der absolute Wahnsinn.
Zurück zum Thema:
Ich habe ihn wieder gangbar bekommen, nachdem ich ihn komplett zurückgesetzt habe. Bisher sieht es auch gut aus, was das Thema Discards angeht. Ich werde weiter beobachten. Einzig der Backup2, der nur mit 1xGbit per Kupfer angebunden ist, schreibt ab und zu bis 2,5% Discards raus. Das führe ich vorerst auf Last zurück, weil es immer dann ist, wenn die Syncs starten.
Keine Ahnung wie das bei der neuen CBS-Serie ist. Generell ist es gerade absolut erschreckend was auf dem Markt für Business Switches und Router los ist. Ich dachte, nach fast zwei Jahren Durststrecke bekommen die Hersteller mal ihre Probleme auf die Kette. Leider Fehlanzeige. Es ist durch die Bank weg nichts lieferbar oder Preise wo einem schlecht wird.
Selbst Mikrotik, die bei mir als beliebter Notnagel gelten, ist in Deutschland in den letzten Wochen quasi ausgestorben. Wenn man mehr als ein Gerät bestellen will, kann man das vergessen. Oder bei Ruckus im Juli noch für 2000€ einen 7150-48P gekauft, jetzt zahlt man 3500€. Der absolute Wahnsinn.
Zurück zum Thema:
Ich habe ihn wieder gangbar bekommen, nachdem ich ihn komplett zurückgesetzt habe. Bisher sieht es auch gut aus, was das Thema Discards angeht. Ich werde weiter beobachten. Einzig der Backup2, der nur mit 1xGbit per Kupfer angebunden ist, schreibt ab und zu bis 2,5% Discards raus. Das führe ich vorerst auf Last zurück, weil es immer dann ist, wenn die Syncs starten.
weil das bei jeder Produktserie irgendein ein anderes OS drauf war.
Das ist richtig aber das CLI ist zu 98% Cisco IOS oder IOS-XE identisch! 😉 Kommt man also sehr schnell mit klar.Bei dem einen kann man das nicht, bei einem kann man jenes nicht.
Eigentlich nein. Die CLI Syntax ist vollkommen identisch zw. den Modellen. Wenn aber ein Feature in einem Model nicht unterstützt wird ist das CLI Kommando dann auch nicht da, was ja verständlich ist. Die Syntax zw. SG und CBS ist identisch. Die letzten 2 Images sind Hybridimages die auf beiden HW Plattformen laufen. Folglich ist auch die Syntax gleich.bekommen die Hersteller mal ihre Probleme auf die Kette. Leider Fehlanzeige.
Liegt ja nicht an den Herstellern sondern an der Chipknappheit generell. Die normalisiert sich ja gerade aber bis man das in den Lieferketten spürt wird das noch ½ Jahr dauern, mindestens.... Die können die Geräte dadurch schlicht und einfach nicht produzieren weil Zulieferteile fehlen. Sieh dir die derzeitigen Lieferzeiten der renomierten Hersteller an!! Das gilt ebenso für Netzteile und andere Komponenten die aus fremden Zulieferketten kommen. Der Fluch der Globalisierung. 😉 Ist ja nicht nur bei Mikrotik so...das Drama gibts ja auch beim Raspberry Pi und anderen...350€ irre. Es gibt endlos Beispiele dazu. Ist aber in der Tat ein ganz anderes Thema...Bisher sieht es auch gut aus, was das Thema Discards angeht.
Das gute alte Winblows Motto...reboot tut gut hilt manchmal auch bei der Infrastruktur. 🤣Hoffen wir mal das es so bleibt.
Zitat von @aqui:
Hoffen wir mal das es so bleibt.
Bisher sieht es auch gut aus, was das Thema Discards angeht.
Das gute alte Winblows Motto...reboot tut gut hilt manchmal auch bei der Infrastruktur. 🤣Hoffen wir mal das es so bleibt.
Es ist wirklich verblüffend. Bei dem SG350X, der anfangs nur mit 1xGbit LWL angebunden war und es viele Discards gab, hat die LAG mit 2x10Gbit ware Wunder bewirkt. Was erstmal logisch klingen mag, aber bei der Auslastung hätte die 1Gbit LWL nicht überfordert sein dürfen.
Auch die Discards am Core ICX7750 sind an allen Schnittstellen weniger geworden. Mittlerweile vermute ich, das die Cut-Through-Option auch funktioniert bei 1Gbit, dort aber zu Problemen führt. Er scheint also nicht zu erkennen, das es nicht kompatibel ist und schaltet auf store-and-forward um. Bei den 10Gbit ist durch die Band weg kein einziger Discard.
Vermutlich muss ich den kompletten Switch auf Store-and-Forward umstellen, um auch einen reibungslosen Hybrid-Betrieb mit 1Gbit zu gewährleisten.
Was erstmal logisch klingen mag, aber bei der Auslastung hätte die 1Gbit LWL nicht überfordert sein dürfen.
Hast du auf dem 350X das Jumbo Framing aktiviert?? Sollte man bei Geräten mit 10G Interfaces und höher generell IMMER machen.
Vermutlich muss ich den kompletten Switch auf Store-and-Forward umstellen
Den ASIC Mode kannst du niemals per Konfig umstellen. Das ist immer fest im Silizium verankert. Weisst du als Profi ja auch selber. 😉Zitat von @aqui:
Den ASIC Mode kannst du niemals per Konfig umstellen. Das ist immer fest im Silizium verankert. Weisst du als Profi ja auch selber. 😉
Den ASIC Mode kannst du niemals per Konfig umstellen. Das ist immer fest im Silizium verankert. Weisst du als Profi ja auch selber. 😉
Das ist leider falsch, da muss ich dich korrigerien... das ich diesen Moment noch erleben darf:
Der ICX7750 kann beide Modis. Per Default macht er Cut-Through, du kannst aber einfach auf der CLI...
store-and-forward...abfeuern und dann verwendet er global diesen Modus auch an 10G. Im Default, laut Ruckus, läuft er im Cut-Through und macht es angeblich lt Doku nicht für 1G, sondern nur für 10G. Was aber nicht genau geschrieben steht, sondern eher wage formuliert wurde. Kann also gut sein, das bei Cut-Through auch 1G angewendet wird und dann eben solche Begleiterscheinungen eintreten. Möglich wäre es.
https://docs.commscope.com/bundle/fastiron-08092-managementguide/page/GU ...
Zum Thema Jumbo: Ich habe tatsächlich Standard aktiv... das würde bedeuten ich müsste jeden Client und jeden Switch im Netz auf Jumbo Frames bringen, korrekt? Was würde passieren wenn die CLients nicht MTU9000 unterstützen, ist dann mit Problemen zu rechnen oder sendet nur der Switch dann zum nächsten einfach mit Jumbo?
Der ICX7750 kann beide Modis.
Ooops...wie peinlich! Shame on me... 🙈ich müsste jeden Client und jeden Switch im Netz auf Jumbo Frames bringen, korrekt?
Nope, Clients handeln das dynamisch aus. Stichwort Path MTU DiscoveryEs sei denn sie sind im (alten) Treiber auf 1500er MTU festgenagelt. Zumindestens bei Server und Storage sollte man das immer prüfen.
oder sendet nur der Switch dann zum nächsten einfach mit Jumbo?
Nein, der gesamte Pfad muss das können. Bei der PMTUD gewinnt immer das kleinste gemeinsame Vielfache. 😉
Interessant. Seitdem ich bei einigen Geräten jetzt Jumbo Frames aktiviert habe, kommt es vermehrt wieder zu Discards. Ich kann jetzt nicht so ohne weiteres sagen, woher der Traffic kam, der die DIscards verursacht hat... zumindest mal ist der betreffende Client und alle Switches im Netz auf mtu 9000.
Das ist schon etwas mystisch... Sind die NIC Treiber der Endgeräte auf dem aktuellsten (Hersteller) Stand? (Keine embeddeten Treiber verwenden.)
So pauschal kann man das nicht sagen, weil die Varianz an Geräten ist mittlerweile nicht mehr überschaubar. Spezifisch vor allem bei Servern, kann ich sagen - Ja - auf aktuellem Stand. Aber bei Client sind mitterweile gefühlt 20 verschiedene Modelle von unterschiedlichen Herstellern 100-fach im Einsatz.
Konkret habe ich gerade einen Fall, den ich sogar reproduzieren kann:
Windows 10 Client - ziemlich alte Büchse von Fujitsu, aber die letzten Treiber die es für den gab sind installiert. Dieser hängt noch an einem Mini-Switch, dieser wiederum per Kupfer an einem ICX7250 und jener ist verbunden mit dem Core per LWL über LAG.
Wenn auf diesem besagten CLient einen reboot durchführe und nach Anmeldung sich die Laufwerke einhängen. Dann wird auf dem ICX7250 und auf dem Core Discards zwischen 2,5 - 4% gemeldet. Zeitgleich. Genau für diesen Weg, zu diesem Client.
Da ist dann die Frage ob das normales Verhalten ist oder ein Problem. Denn per se sind Discards rein für sich ja noch kein Problem. Schwierig. Vorallem beim Arbeiten mit diesem Rechner merke ich auch keinen Unterschied zu einem anderen Rechner der dieses Verhalten nicht zeigt.
Konkret habe ich gerade einen Fall, den ich sogar reproduzieren kann:
Windows 10 Client - ziemlich alte Büchse von Fujitsu, aber die letzten Treiber die es für den gab sind installiert. Dieser hängt noch an einem Mini-Switch, dieser wiederum per Kupfer an einem ICX7250 und jener ist verbunden mit dem Core per LWL über LAG.
Wenn auf diesem besagten CLient einen reboot durchführe und nach Anmeldung sich die Laufwerke einhängen. Dann wird auf dem ICX7250 und auf dem Core Discards zwischen 2,5 - 4% gemeldet. Zeitgleich. Genau für diesen Weg, zu diesem Client.
Da ist dann die Frage ob das normales Verhalten ist oder ein Problem. Denn per se sind Discards rein für sich ja noch kein Problem. Schwierig. Vorallem beim Arbeiten mit diesem Rechner merke ich auch keinen Unterschied zu einem anderen Rechner der dieses Verhalten nicht zeigt.
Ich habe das hier einmal live auf 2 ICX 7150 kontrolliert. An einem ist ein Host mit einer 10G XFG Optik dran und beide Switches sind mit einem 10G SFP+ Link verbunden. Am 2ten hängt ein NAS ebenfalls mit 10G.
Über 1 ½ Wochen mit diversen Peak Lasten mal gemonitored und alle Errorcounter aller beteiligten Interfaces bleiben da auf 0. (Firmware 8.0.95h)
(Zur Zeit des Screenshots war nix los. 
)
Über 1 ½ Wochen mit diversen Peak Lasten mal gemonitored und alle Errorcounter aller beteiligten Interfaces bleiben da auf 0. (Firmware 8.0.95h)
300 second input rate: 610904 bits/sec, 75 packets/sec, 0.00% utilization
300 second output rate: 82784 bits/sec, 41 packets/sec, 0.00% utilization
1239212 packets input, 800684873 bytes, 0 no buffer
Received 66293 broadcasts, 63196 multicasts, 1109723 unicasts
0 input errors, 0 CRC, 0 frame, 0 ignored
0 runts, 0 giants
979537 packets output, 475115697 bytes, 0 underruns
Transmitted 16135 broadcasts, 15071 multicasts, 948331 unicasts
0 output errors, 0 collisions
Relay Agent Information option: Disabled
Protected: No
MAC Port Security: Disabled
This port is not being monitored for queue drops
Egress queues:
Queue counters Queued packets Dropped Packets
0 969483 0
1 0 0
2 0 0
3 0 0
4 4656 0
5 302 0
6 3225 0
7 1871 0
Dann verstehe ich es nicht. Habe eine immense Masse an unterschiedlichen Geräten im Einsatz, da fällt es mir schwer zu überblicken ob es normales Verhalten oder irgendein Software-/Hardware-Problem ist. Leider bringt das diese Branche, für die ich tätig bin so mit sich. Ständig wird von irgendwelchen Drittanbietern minderwertige Hardware eingebracht und die Software die da drauf läuft kommt aus der Steinzeit. Es wird den Verantwortlichen als Neu verkauft und die schlagen dann zu. Dann wird man vor vollendete Tatsachen gestellt und darf sich dann kümmern wie der Dreck ordentlich funktioniert. Echt frustrierend.
Man kann da noch so gute Netzwerkkomponenten im Einsatz haben, wenn die Endgeräte Müll sind, bringt es alles nichts.
Das mal zum gegenwärtigen Stand, zurück zum Thema:
Mittlerweile beschränken sich die Probleme auf wenige andere Systeme. Initial das Problem mit dem Backup-Server scheint gelöst, da gab es keine Meldungen mehr und auch keine gedroppten Pakete. Bisher habe ich nur ein VLAN auf Jumbo Frames eingestellt und dort scheint Ruhe eingekehrt zu sein. Wobei dort eher sporadisch mal ein 1Gbit LAG zu einem SG300 ausgehend vom Core meckert. Am meisten tauchen jetzt eher Access-Verbindungen auf, da könnte man jetzt konsequent weiter machen und alles auf Jumbo umstellen. Ob das überall so ohne weiteres möglich ist, bleibt abzuwarten.
Gegenwärtig bereitet mir nur noch die pfSense wirklich Sorge. Dort ist trotz laufendem LAG mit LACP und Jumbo, immer mal wieder ein Schwung an Paketen gedroppt worden.
Man kann da noch so gute Netzwerkkomponenten im Einsatz haben, wenn die Endgeräte Müll sind, bringt es alles nichts.
Das mal zum gegenwärtigen Stand, zurück zum Thema:
Mittlerweile beschränken sich die Probleme auf wenige andere Systeme. Initial das Problem mit dem Backup-Server scheint gelöst, da gab es keine Meldungen mehr und auch keine gedroppten Pakete. Bisher habe ich nur ein VLAN auf Jumbo Frames eingestellt und dort scheint Ruhe eingekehrt zu sein. Wobei dort eher sporadisch mal ein 1Gbit LAG zu einem SG300 ausgehend vom Core meckert. Am meisten tauchen jetzt eher Access-Verbindungen auf, da könnte man jetzt konsequent weiter machen und alles auf Jumbo umstellen. Ob das überall so ohne weiteres möglich ist, bleibt abzuwarten.
Gegenwärtig bereitet mir nur noch die pfSense wirklich Sorge. Dort ist trotz laufendem LAG mit LACP und Jumbo, immer mal wieder ein Schwung an Paketen gedroppt worden.
Ne pfSense (APU Basis) ist übrigens an dem o.a. Switch auch dran. Hängt aber per Cu an einem SG350-X der dann mit 10G auf den ICX terminiert. Leider ohne LAG, deshalb ist das etwas Äpfel mit Birnen...
Beide aber der pfSense Cu Port am 350er und der 10G Koppelport sind vollkommen unauffällig. Dort ist ein permanenter Datenfluss bedingt durch die Internet Kopplung (1G sym) und auch da bleiben alle Counter auf 0 und haben noch nie hochgezählt.
Vermutlich ist das irgendein Endgerät was eine defekte NIC oder ein defekten PHY hat und der Cut Through Switch das weiterreicht. Schwer zu troubleshooten... Am effizientesten ist Top Talker mal auf andere Ports an Store and Forward Hardware umzuhängen und zu checken ob die Counter sich ändern. Da das bei dir in sehr kurzen Zeitabständen hochzählt müsste es ja etwas sein was schon ein relevantes Traffic Volumina erzeugt.
Beide aber der pfSense Cu Port am 350er und der 10G Koppelport sind vollkommen unauffällig. Dort ist ein permanenter Datenfluss bedingt durch die Internet Kopplung (1G sym) und auch da bleiben alle Counter auf 0 und haben noch nie hochgezählt.
Vermutlich ist das irgendein Endgerät was eine defekte NIC oder ein defekten PHY hat und der Cut Through Switch das weiterreicht. Schwer zu troubleshooten... Am effizientesten ist Top Talker mal auf andere Ports an Store and Forward Hardware umzuhängen und zu checken ob die Counter sich ändern. Da das bei dir in sehr kurzen Zeitabständen hochzählt müsste es ja etwas sein was schon ein relevantes Traffic Volumina erzeugt.
Mittlerweile glaube ich das es am Cut-Through-Mode und dem MischMasch an Uplinks liegt. Deshalb werde ich jetzt mal hart store-and-forward konfigurieren. Danach werde ich die ganze Sache nochmal beobachten.
Generell muss ich aber feststellen das in den letzten Tagen die Discards, die über 2% liegen, weniger geworden sind. Das kann eigentlich nur an der MTU liegen, das war die letzte Aktion. Reproduzieren lässt sich das Verhalten entweder bei sequentieller Volllast - was kein wirklicher Anwendungsfall ist - oder wenn ich bestimmte Prozeduren an bestimmten Clients ausführe. Leider sind die Bilder, die sich daraus ergeben, nicht logisch. Komisch ist auch, das sich die Probleme immer am Core (ICX7750) kanalisieren. Somit wäre der Schritt mit store-and-forward die naheliegenste Maßnahme.
Man darf gespannt sein.
Generell muss ich aber feststellen das in den letzten Tagen die Discards, die über 2% liegen, weniger geworden sind. Das kann eigentlich nur an der MTU liegen, das war die letzte Aktion. Reproduzieren lässt sich das Verhalten entweder bei sequentieller Volllast - was kein wirklicher Anwendungsfall ist - oder wenn ich bestimmte Prozeduren an bestimmten Clients ausführe. Leider sind die Bilder, die sich daraus ergeben, nicht logisch. Komisch ist auch, das sich die Probleme immer am Core (ICX7750) kanalisieren. Somit wäre der Schritt mit store-and-forward die naheliegenste Maßnahme.
Man darf gespannt sein.
store-and-forward konfigurieren. Danach werde ich die ganze Sache nochmal beobachten.
Das ist in der Tat spannend. Wie gesagt ein größeres Netz hier im Core und Distribution mit ICX (alle SaF), 10G Backbone und Access diverse Cisco SG250X/250X über Monate keinerlei Hochzählen irgendwelcher Error Counter. Egal welcher Switch und Port.
