Gelöst
Betreff: Störungsmeldung / ASIC-Firmware-Bug (Hash Polarization) auf dem Telekom-Switch (Aruba AOS-S) Aruba 2930
vor 7 Tagen
Hinweis: Da mein Deutsch nicht perfekt ist, wurde dieser Text mit Unterstützung einer KI formuliert, um die technischen Details so präzise wie möglich zu beschreiben.
***
Sehr geehrte Damen und Herren vom Network Engineering / NOC,
wir haben ein persistentes und reproduzierbares L4-Hashing- / Packet-Reordering-Problem auf dem von Ihnen bereitgestellten Switch (vermutlich Aruba 2530/2930 / AOS-S) festgestellt. Der Fehler betrifft ausschließlich eingehenden (Inbound) UDP-gekapselten Traffic (z.B. L2TP-Tunnel, VNC) und tritt nur bei Ziel-Hosts auf, deren MAC-Adresse einen GERADEN Hash-Wert aufweist (das niederwertigste Bit des letzten Bytes ist 0, z.B. Endungen auf :88, :98).
Technische Details und Fehlerbeschreibung:
1. Nativer TCP-Traffic (Speedtest, nativer iperf3 TCP) läuft problemlos mit vollen ~700/500 MBit/s auf allen MAC-Adressen.
2. Sobald UDP-Traffic in einem Tunnel über ca. 80 MBit/s ansteigt, kommt es zu massivem Paket-Reordering. Log-Ausgabe von iperf3: "iperf3: OUT OF ORDER - incoming packet = X and received packet = Y".
3. TCP-Sitzungen (wie SSH/SFTP via MC), die INNERHALB dieses UDP-Tunnels laufen, brechen aufgrund des Out-of-Order-Traffics und des kollabierenden TCP-Window-Scalings auf ca. 1 MBit/s ein.
4. Ändert man die MAC-Adresse des Hosts auf einen UNGERADEN Hash-Wert (das niederwertigste Bit ist 1, z.B. Endung auf :93), verschwindet das Problem sofort. Der Tunnel erreicht die volle Leitungsgeschwindigkeit.
Fazit ii:
Es handelt sich hierbei um einen bekannten Architektur-/Firmware-Bug im ProVision ASIC L4 Load-Sharing / Packet Parsing Algorithmus von Aruba (AOS-S). Bei geraden MAC-Hashes verteilt der Switch sequentielle Pakete desselben UDP-Tunnels fälschlicherweise auf unterschiedliche interne Verarbeitungspfade, was zu einer Out-of-Order-Zustellung führt.
Bitte leiten Sie dieses Ticket an die zuständige Fachabteilung weiter, damit das Problem dort geprüft und reproduziert werden kann. Bei Bedarf kann ich den Fehler jederzeit live vorführen sowie die genauen Adressen und IP-Daten bereitstellen, an denen die Störung auftritt.
Mit freundlichen Grüßen,
Alexander
135
0
21
Das könnte Ihnen auch weiterhelfen
vor 5 Stunden
36
0
3
96
0
8
in
25
0
1
in
86
0
11
Beliebte Tags letzte 7 Tage
Das könnte Sie auch interessieren
Kaufberatung anfragen
Füllen Sie schnell und unkompliziert unser Online-Kontaktformular aus, damit wir sie zeitnah persönlich beraten können.
Angebote anzeigen
Informieren Sie sich über unsere aktuellen Internet-Angebote.
vor 7 Tagen
Schmeiß dein KI Müll weg - zum übersetzten isses okay - und beschreibe dein Problem und dein Netzwerk.
0
0
vor 7 Tagen
Fazit ii:
Es handelt sich hierbei um einen bekannten Architektur-/Firmware-Bug im ProVision ASIC L4 Load-Sharing / Packet Parsing Algorithmus von Aruba (AOS-S). Bei geraden MAC-Hashes verteilt der Switch sequentielle Pakete desselben UDP-Tunnels fälschlicherweise auf unterschiedliche interne Verarbeitungspfade, was zu einer Out-of-Order-Zustellung führt.
Bitte leiten Sie dieses Ticket an die zuständige Fachabteilung weiter, damit das Problem dort geprüft und reproduziert werden kann. Bei Bedarf kann ich den Fehler jederzeit live vorführen sowie die genauen Adressen und IP-Daten bereitstellen, an denen die Störung auftritt.
Hinweis: Da mein Deutsch nicht perfekt ist, wurde dieser Text mit Unterstützung einer KI formuliert, um die technischen Details so präzise wie möglich zu beschreiben.
***
Sehr geehrte Damen und Herren vom Network Engineering / NOC,
wir haben ein persistentes und reproduzierbares L4-Hashing- / Packet-Reordering-Problem auf dem von Ihnen bereitgestellten Switch (vermutlich Aruba 2530/2930 / AOS-S) festgestellt. Der Fehler betrifft ausschließlich eingehenden (Inbound) UDP-gekapselten Traffic (z.B. L2TP-Tunnel, VNC) und tritt nur bei Ziel-Hosts auf, deren MAC-Adresse einen GERADEN Hash-Wert aufweist (das niederwertigste Bit des letzten Bytes ist 0, z.B. Endungen auf :88, :98).
Technische Details und Fehlerbeschreibung:
1. Nativer TCP-Traffic (Speedtest, nativer iperf3 TCP) läuft problemlos mit vollen ~700/500 MBit/s auf allen MAC-Adressen.
2. Sobald UDP-Traffic in einem Tunnel über ca. 80 MBit/s ansteigt, kommt es zu massivem Paket-Reordering. Log-Ausgabe von iperf3: "iperf3: OUT OF ORDER - incoming packet = X and received packet = Y".
3. TCP-Sitzungen (wie SSH/SFTP via MC), die INNERHALB dieses UDP-Tunnels laufen, brechen aufgrund des Out-of-Order-Traffics und des kollabierenden TCP-Window-Scalings auf ca. 1 MBit/s ein.
4. Ändert man die MAC-Adresse des Hosts auf einen UNGERADEN Hash-Wert (das niederwertigste Bit ist 1, z.B. Endung auf :93), verschwindet das Problem sofort. Der Tunnel erreicht die volle Leitungsgeschwindigkeit.
Fazit ii:
Es handelt sich hierbei um einen bekannten Architektur-/Firmware-Bug im ProVision ASIC L4 Load-Sharing / Packet Parsing Algorithmus von Aruba (AOS-S). Bei geraden MAC-Hashes verteilt der Switch sequentielle Pakete desselben UDP-Tunnels fälschlicherweise auf unterschiedliche interne Verarbeitungspfade, was zu einer Out-of-Order-Zustellung führt.
Bitte leiten Sie dieses Ticket an die zuständige Fachabteilung weiter, damit das Problem dort geprüft und reproduziert werden kann. Bei Bedarf kann ich den Fehler jederzeit live vorführen sowie die genauen Adressen und IP-Daten bereitstellen, an denen die Störung auftritt.
Mit freundlichen Grüßen,
Alexander
Bitte watt? Ja genau, wird gemacht. Nö, doch nicht.
0
0
vor 7 Tagen
Hey please to because manufacturers will so Aruba
@Alex7878d8
0
14
von
vor 7 Tagen
https://www.speedtest.net/ru/result/19640952574
Der Speedtest-Link zeigt die Internetnutzung von Deutschen Telekom
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
und solltest daran im Maximum 1000 Mbit/s im Download und 600 Mbit/s im Upload haben
0
von
vor 7 Tagen
Der Speedtest-Link zeigt die Internetnutzung von Deutschen Telekom
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
und solltest daran im Maximum 1000 Mbit/s im Download und 600 Mbit/s im Upload haben
https://www.speedtest.net/ru/result/19640952574
Der Speedtest-Link zeigt die Internetnutzung von Deutschen Telekom
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
und solltest daran im Maximum 1000 Mbit/s im Download und 600 Mbit/s im Upload haben
Ok, kein Telekomkunde. Dann wird dich dein Anbieter weiterinformieren. Nehme mal an 1&1 oder VF ...O2 ggf... von dir gibt es bei der Telekom keine Daten und man kann dich da leider nicht unterstützen.
Hinweis:
von
vor 7 Tagen
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
https://www.speedtest.net/ru/result/19640952574
Der Speedtest-Link zeigt die Internetnutzung von Deutschen Telekom
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
und solltest daran im Maximum 1000 Mbit/s im Download und 600 Mbit/s im Upload haben
Dann ist aber dein Ansprechpartner die IT Abteilung deines Unternehmens und nicht direkt die Telekom. Nur der Vertragsinhaber kann ein Problem melden.
Uneingeloggter Nutzer
von
vor 7 Tagen
Es handelt sich hierbei um einen bekannten Architektur-/Firmware-Bug im ProVision ASIC L4 Load-Sharing / Packet Parsing Algorithmus von Aruba (AOS-S).
Hinweis: Da mein Deutsch nicht perfekt ist, wurde dieser Text mit Unterstützung einer KI formuliert, um die technischen Details so präzise wie möglich zu beschreiben.
***
Sehr geehrte Damen und Herren vom Network Engineering / NOC,
wir haben ein persistentes und reproduzierbares L4-Hashing- / Packet-Reordering-Problem auf dem von Ihnen bereitgestellten Switch (vermutlich Aruba 2530/2930 / AOS-S) festgestellt. Der Fehler betrifft ausschließlich eingehenden (Inbound) UDP-gekapselten Traffic (z.B. L2TP-Tunnel, VNC) und tritt nur bei Ziel-Hosts auf, deren MAC-Adresse einen GERADEN Hash-Wert aufweist (das niederwertigste Bit des letzten Bytes ist 0, z.B. Endungen auf :88, :98).
Technische Details und Fehlerbeschreibung:
1. Nativer TCP-Traffic (Speedtest, nativer iperf3 TCP) läuft problemlos mit vollen ~700/500 MBit/s auf allen MAC-Adressen.
2. Sobald UDP-Traffic in einem Tunnel über ca. 80 MBit/s ansteigt, kommt es zu massivem Paket-Reordering. Log-Ausgabe von iperf3: "iperf3: OUT OF ORDER - incoming packet = X and received packet = Y".
3. TCP-Sitzungen (wie SSH/SFTP via MC), die INNERHALB dieses UDP-Tunnels laufen, brechen aufgrund des Out-of-Order-Traffics und des kollabierenden TCP-Window-Scalings auf ca. 1 MBit/s ein.
4. Ändert man die MAC-Adresse des Hosts auf einen UNGERADEN Hash-Wert (das niederwertigste Bit ist 1, z.B. Endung auf :93), verschwindet das Problem sofort. Der Tunnel erreicht die volle Leitungsgeschwindigkeit.
Fazit ii:
Es handelt sich hierbei um einen bekannten Architektur-/Firmware-Bug im ProVision ASIC L4 Load-Sharing / Packet Parsing Algorithmus von Aruba (AOS-S). Bei geraden MAC-Hashes verteilt der Switch sequentielle Pakete desselben UDP-Tunnels fälschlicherweise auf unterschiedliche interne Verarbeitungspfade, was zu einer Out-of-Order-Zustellung führt.
Bitte leiten Sie dieses Ticket an die zuständige Fachabteilung weiter, damit das Problem dort geprüft und reproduziert werden kann. Bei Bedarf kann ich den Fehler jederzeit live vorführen sowie die genauen Adressen und IP-Daten bereitstellen, an denen die Störung auftritt.
Mit freundlichen Grüßen,
Alexander
Dann wende dich an HPE Aruba Networking?
1
von
vor 7 Tagen
Vielen Dank für Ihre Antwort.
Allerdings macht ein Ticket beim HPE/Aruba-Support meinerseits keinen Sinn, da ich weder der Administrator dieses Switches bin noch für einen Internetanbieter in Deutschland arbeite. Endkunden ohne direkten Wartungsvertrag haben keinen Zugriff auf den Support des Hardware-Herstellers.
Ich bin mir zwar nicht sicher, ob die Hardware physisch der Telekom gehört, aber die IP-Adresse im WHOIS ist eindeutig auf die Deutsche Telekom registriert. Daher kann dieses Problem nur von der Telekom selbst oder vom Administrator der Organisation gelöst werden, die dieses Adresspräfix und die Infrastruktur von der Telekom mietet.
Da ich selbst über Erfahrung in der Netzwerkadministration bei Internetdienstanbietern (ISPs) verfüge, konnte ich das Problem bis auf die Protokollebene lokalisieren.
Bitte leiten Sie diese technische Analyse an das zuständige Network Engineering oder an das entsprechende Support-Team weiter, damit die Administratoren, die Zugriff auf das System und den Herstellersupport haben, den Fehler prüfen können.
0
Uneingeloggter Nutzer
von
Akzeptierte Lösung
akzeptiert von
vor 7 Tagen
Der Speedtest-Link zeigt die Internetnutzung von Deutschen Telekom
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
und solltest daran im Maximum 1000 Mbit/s im Download und 600 Mbit/s im Upload haben
https://www.speedtest.net/ru/result/19640952574
Der Speedtest-Link zeigt die Internetnutzung von Deutschen Telekom
Ich habe keinen direkten Vertrag, nutze aber den Internetanschluss der Deutschen Telekom
und solltest daran im Maximum 1000 Mbit/s im Download und 600 Mbit/s im Upload haben
Ok, kein Telekomkunde. Dann wird dich dein Anbieter weiterinformieren. Nehme mal 1&1 oder VF ...O2 ggf... von dir gibt es bei der Telekom keine Daten und man kann dich da leider nicht unterstützen.
Hinweis:
0
vor 7 Tagen
Nur für die Statistik
0
Uneingeloggter Nutzer
von