[eos][Network] Netzwerk-Degradierung mit Public IP(v4)

    Es scheint Public IPv4 Adressen zu geben, die massive Probleme mit dem Netzwerkverkehr haben.
    Paketverlust größer 50% und sehr geringe Bandbreiten (teilweiße einstellige Mbit/s oder sogar 0,X)
    Betroffen: 159.195.160.132 (nicht betroffen: 159.195.160.133)
    Über den Messzeitraum 24h wurden folgende Ergebnisse gemittelt (Detail-Graph unten):

    Quelle ↓ / Ziel →AB über ded. IPv4 (*.132)B über Port-ForwardC (*.133)Extern
    A—🔴 54 Mbit/s · 50 % Loss🟢 1087 Mbit/s · 0,00 % Loss🟢 1087 Mbit/s · 0,00 %Loss🟢 1008 Mbit/s · 0,00 % Loss
    B (via pub. IPv4)🔴 81 Mbit/s · 45 % Loss——🔴 36 Mbit/s · 56 % Loss🔴 14 Mbit/s · 53 % Loss
    C🟢 1083 Mbit/s · 0,00 % Loss🔴 126 Mbit/s · 52 % Loss🟢 1086 Mbit/s · 0,00 % Loss—🟢 1009 Mbit/s · 0,00 % Loss
    Extern🟢 885 Mbit/s🔴 241–1073 Mbit/s
    (stark schwankend) ·
    25-63% Loss    		– (nicht gemessen)🟢 879 Mbit/s🟢 2,5 Gbit/s

    Ping-Loss zeigt dasselbe Bild: →B ded. IP 10–19 % Mittel (Spitzen bis 55 %), →B Port-Forward 0 % über alle Messungen, alle Kontrollpfade 0 %.

    • B über Port-Forward: keinerlei Problem. Messungen aus beiden Quellen mit 0,00 % UDP-Loss, 0 % Ping-Loss, TCP nie unter 1076 Mbit/s — identisch zu allen gesunden Pfaden.
    • B über dedizierte IPv4: massiv gestört, eingehend wie ausgehend. B's ausgehender Verkehr nutzt wohl denselben defekten Edge-Pfad — egal welcher Zielpfad.
    • Extern→B (TCP-Gegenrichtung über dieselbe Session zur ded. IPv4): ebenfalls degradiert.

    A/B-Test:

    Dedizierte IPv4 von B abgehängt → B's Egress läuft über die Netz-Default-IP und ist sofort perfekt: 1094 Mbit/s · 0,00 % Loss · 0 % Ping-Loss.
    Wieder angehängt → sofort wieder 3 Mbit/s · 61 % · 42 % Ping-Loss.
    Dedizierte IPv4 von B umgehängt and D → D hat sofort die selben Probleme:

    • Ping-Loss: 30 % (Server B: 26–42 %)
    • TCP fwd: 1,78 Mbit/s (Server B: 0,4–3,4 Mbit/s)
    • TCP rev: 134 Mbit/s (Server B: 132,9–134,1 Mbit/s)
    • UDP-Loss: 49 % (Server B: 55,92–60,95 %)

    Detach/Re-Attach hilft also nicht - daher "hängt" der Fehler wohl an der IP.

    Testaufbau:
    - Server A - Realm 1, Netz 1A ,known good Netz mit public IPv4
    - Server B - Realm 2, Netz 2A, kaputte public IPv4
    - Server C - Realm 2, Netz 2B, funktionierende public IPv4
    - Server D - Realm 2 Netz 2A, spontan erzeugt zum test
    - Extern - öffentliche Speedtests und einer meiner Server mit 2,5 Gbit/s

    Verlauf:
    zeitverlauf-server-b-v3.png

    Zitat von [netcup eos] Stephan P.

    Kannst du bitte kurz prüfen ob unser Fix dein Problem auch wirklich behebt? Ich will nur ausschliessen dass hier noch ein weiteres Problem besteht dass wir bisher nicht nachstellen konnten.

    Hallo zusammen, hallo Stephan,

    wir sehen exakt dasselbe Problem auf unserem Server 159.195.213.13x (eos-Plattform, Gateway 159.195.212.1) — und es besteht auch nach dem angekündigten Fix weiterhin (Stand: 10.08., ca. 15:00 UTC).

    Symptome: wiederkehrende Episoden von mehreren Minuten, in denen die RTT zum First-Hop-Gateway 159.195.212.1 konstant bei 1400–1500 ms liegt, mit ca. 30 % Paketverlust (fehlende icmp_seq im Log). Zwischen den Episoden sind es normale 0,5 ms. Der Durchsatz bricht während der Episoden auf einstellige kB/s ein (apt-Download vom Ubuntu-Mirror: 18 kB/s, HTTPS-Request zu google.com: mehrere Sekunden statt ~30 ms).

    Auszug aus dem Ping-Log (ping -D, Unix-Timestamps, heute ~14:55 UTC):

    [1786373732.573970] icmp_seq=1 time=8.55 ms
    [1786373735.696893] icmp_seq=2 time=1129 ms
    [1786373737.989938] icmp_seq=3 time=1420 ms (seq 4–5 verloren)
    [1786373746.075567] icmp_seq=7 time=1456 ms
    ...
    [1786373852.401313] icmp_seq=60 time=1415 ms
    [1786373854.989961] icmp_seq=62 time=0.528 ms ← Episode endet abrupt
    [1786373862.389233] icmp_seq=65 time=1334 ms ← nächste beginnt sofort

    Wir haben ausgeschlossen, dass die Ursache in unserer VM liegt: Während der Episoden lag unser Egress-Traffic bei ~50 B/s, tc -s qdisc zeigte backlog 0b 0p in allen Queues (0 dropped), Interface-Counter ohne Errors/Drops, CPU idle, kein Steal. Die Queue entsteht also außerhalb der VM, auf dem Host/Access-Layer.

    mtr bestätigt: Verlust und Latenz beginnen ab Hop 1 (159.195.212.2, AS197540).

    @Stephan: Betrifft der ausgerollte Fix auch das Subnetz 159.195.212.0/22 bzw. unsere Node? Bei uns ist keine Besserung erkennbar. Weitere Logs (mtr-Report, vollständiges Ping-Log mit Timestamps, qdisc-Statistiken) liefere ich gerne nach.

    Viele Grüße