Beiträge von Sergo

    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