Das längste Thema

    Zitat von AccountSuspended

    Ich habe leider die alten Informationen nicht mehr zu dem Server und die Antwort vom Support.

    Ich habe es etwas anders in Erinnerung aber das wird schon stimmen. Soweit ich es aber in Erinnerung habe, war da ein Nachteil gegenüber dem Traffic der aktuellen Generation vorhanden :/

    Bei mir ist es eher Kopfsache daher begrüße ich nicht von einem monatlichen Limit zu lesen :D

    Naja, das monatliche Limit kannst du dir ja ausrechnen. Wird wohl grob bei 3TB/Tag und damit 90 TB/Monat liegen.

    Zitat von tab

    Naja, das monatliche Limit kannst du dir ja ausrechnen. Wird wohl grob bei 3TB/Tag und damit 90 TB/Monat liegen.

    Ja schon aber ich bin mir nun nicht mehr sicher was danach passierte? Was ist wenn das im Monat (Warum auch immer) verbraucht wurde denke ich mir bei so etwas immer dabei - Klar scheinbar hat man doch noch eine Drosselung drinnen aber dann doch bestimmt langsamer als die aktuellen 300 MBit/s? Wahrscheinlich habe ich diesen monatlichen Traffic mit dem Roten Haus verbunden, wo man ab einem monatlichen Traffic von 20 TB oben drauf zahlen muss :/

    Zitat von Virinum

    Seit 14:51 Uhr klappt die Verbindung zu diesem Host auch wieder. Bei 2602:fdaa:c6:2::ac15:826b drehen die Pakete aber noch ihre Runden. Dadurch klappt aktuell der Connect von https://www.ssllabs.com/ssltest/ nicht.

    Sieht hier auch so aus:

    SSL Labs meldet entsprechend auf IPv6 "Unable to connect to the server" (IPv4 läuft).

    Ist schon übel. Viel schlimmer ist aber, daß ich momentan meine LE-Certs nicht aktualisieren kann, von dort kommt die Meldung

    ["error","detail"] "2a0a:4cc0:c0:xxx: Fetching http://xxx/.well-known/acme-challenge/...: Timeout during connect (likely firewall problem)". Das funktioniert seit Jahren problemlos und das Setup hat sie hier nicht geändert, dürfte also das gleiche Problem sein. Die angegebene URL ist von Zuhause (DSL) und Servern bei anderen Hostern erreichbar, ein Firewall-Problem kann ich ausschließen.

    Wenn sonst niemand was einfällt, würde ich das mal dem Support melden...

    Zitat von jah

    Viel schlimmer ist aber, daß ich momentan meine LE-Certs nicht aktualisieren kann

    Genau dadurch bin ich auch auf das Problem aufmerksam geworden. Letsencrypt versucht es von der IP 2600:3000:2710:300::82. Habe gestern das Ticket NCSUP-684762 eröffnet und es wurde sehr schnell an die entsprechende Abteilung weitergeleitet. Seitdem habe ich nichts mehr gehört. Schadet bestimmt nicht, wenn du dich auch mal bei Support meldest. Kannst gerne meine Ticket-ID referenzieren. Wenn das morgen nicht behoben ist, muss ich wohl mal den Notfall-Support bemühen.

    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    Hi, mal eine Frage.

    Ich habe einen RS der genau dem Angebot RS 2000 G9.5 Pro NUE AUG25 entspricht: https://www.netcup.com/de/server/root…5-pro-nue-aug25

    Ich zahle aber 16.89€ im Monat, statt 12.79€. Besteht die Möglichkeit, das Angebot zu bestellen, den alten zu kündigen, und 2 Monate lang den alten weiterzuzahlen (1 Monat Kündigungsfrist), und man behält den alten dann als den, den man durch das Angebot bekommen würde? Um auf die ganze Migration verzichten zu können? Natürlich dann mit neuer Mindestvertragslaufzeit.

    Vielen Dank im Voraus.

    Meine Einschätzung nach allem, was ich zu diesem und ähnlichen Themen hier von offizieller Seite gelesen habe: Nein, geht nicht. Du wirst um den Umzug also nicht herumkommen, wenn du den alten Server durch einen Aktionsserver ersetzen willst.

    Zitat von AccountSuspended

    hat unbegrenzten Traffic (

    Also ich bin die geschätzt letzten 30 Jahre bei keinem meiner Server mehr in das Monatslimit reingelaufen.

    Für mich ist ein Monatslimit auch erheblich besser als eine Drosselung. Denn WENN ich mal "viel" Traffic brauche, dann ist es sehr ärgerlich, wenn ich z.B. beim Kopieren eines Servers dann mittendrin Gedrosselt werde. Das macht ne flotte Migration so gut wie unmöglich.

    OK, seit Felix weg ist hat mehr als einmal die Drossel bereits weit innerhalb meines Monatslimits zugeschlagen. War jedesmal äzend...

    Das kostet dann jedesmal richtig Geld für die zusätzliche Wartezeit des Technikers.

    Ich komme nur mit Plesk, meiner Meinung nach einer gut besuchten Webseite und einer Owncloud mit 30 Usern auch nicht über 3TB.

    Große Downloads gibt's da aber keine, da muß man nur auf genügend Cores aufpassen, falls hungrige PHP Prozesse ausversehen gleichzeitig alle Cores benutzen.

    Zitat von Virinum

    Genau dadurch bin ich auch auf das Problem aufmerksam geworden. Letsencrypt versucht es von der IP 2600:3000:2710:300::82. Habe gestern das Ticket NCSUP-684762 eröffnet und es wurde sehr schnell an die entsprechende Abteilung weitergeleitet. Seitdem habe ich nichts mehr gehört. Schadet bestimmt nicht, wenn du dich auch mal bei Support meldest. Kannst gerne meine Ticket-ID referenzieren. Wenn das morgen nicht behoben ist, muss ich wohl mal den Notfall-Support bemühen.

    Ich sehe verschiedene IPs von LE bei der Verification, größtenteils AWS (zumindest bei IPv4). Leider versucht LE nach einem Timeout über IPv6 offenbar nicht IPv4. Von einem anderen Serve aus tut es übrigens problemlos, der ist aber auch in einem anderen Netz (2a03:4000:7::/48).

    Ticket hab ich gestern mittag noch aufgemacht, außer der Eingangsbestätigung aber noch nichts gehört.

    Zitat von jah

    Ich sehe verschiedene IPs von LE bei der Verification, größtenteils AWS (zumindest bei IPv4).

    Auf einem anderen Testsystem sehe ich von Letsencrypt Requests von diesen IP-Adressen:

    • 2600:3000:2710:300::82 ❌
    • 2a05:d016:dcc:9100:803e:dd84:3919:e19b ✅
    • 2600:1f16:13c:c402:2b82:665a:7624:3e01 ✅
    • 2406:da18:611:5701:256d:f366:e3ce:9486 ✅
    • 2600:1f14:a8b:500:fce3:7a9d:5408:61e5 ✅
    Zitat von jah

    Leider versucht LE nach einem Timeout über IPv6 offenbar nicht IPv4.

    Das wundert mich auch etwas:

    Zitat von Letsencrypt

    The IPv6 to IPv4 retry only occurs on connection timeouts, not on other types of error.

    EDIT:
    Ah, das ist in meinem Fall die Antwort:

    Zitat von Letsencrypt

    To keep our CA software simple we only perform an IPv6 to IPv4 retry on the first request when validating “http-01” challenges. If you use redirects, the redirects will not get retry treatment.


    Dieses Gebäude hat mir die Vorfahrt genommen! *hup*

    2 Mal editiert, zuletzt von Virinum (27. August 2025 um 09:48)

    Ich hab den ausgehenden Traffic von 3TB bisher in 24h noch nie erreicht, nicht mal beim roten Haus wo einige VM's am laufen hab :-oo und es ist eigentlich einiges los in meinem Netzwerk xD

    • 🇨🇭 | 🇫🇷 | 🇺🇸
    • sudo rm -rf /*all
    • sudo apt-get reinstall ubuntu.exe
    • ping -6 -c 3 172.16.0.1

    Zitat von webdesignheld

    Ich hätte gedacht das Monats limit sind die 3TB am 1. plus die Daten die gedrosselt in den restlichen 2505600 Sekunden umherschwirren.

    Ja, aber die Drosselung auf 300 MBit/s entspricht ja praktisch sogar etwas mehr als 3TB pro Tag. Am allerersten Tag kannst du ein wenig mehr Traffic haben, also 3TB bei maximaler Bandbreite, danach den Rest des Tages 300 MBit/s. Wo man da genau landet hängt von der Bandbreite und Auslastung der Netzwerkanbindung des Nodes ab.

    Obere Grenze für die ersten 24 Stunden ist m.E. in jedem Fall (bei unendlicher Bandbreite) 3GB (in 0 Sekunden :), danach greift sofort die Drosselung) + 86400 * 300 MBit. Also wohl knapp über 6 TB. Danach kannst du im Tagesschnitt Schnitt nicht mehr auf mehr als 300 MBit/s kommen.

    Jedenfalls dann nicht, wenn die 3TB pro Tag ein gleitender Wert sind, also immer über die letzten 24 Stunden berechnet werden. Fängt die Messung z.B. jeden Tag um Mitternacht wieder bei Null an, also ohne die davorliegenden 24 Stunden zu berücksichtigen, dann könntest du das Spielchen vom ersten Tag jeden Tag wiederholen

    Du kannst die durchschnittlichen 300 MBit/s natürlich so verteilen, dass du irgendwann eine Zeit lang wenger als 300 MBit/s verbrauchst und dafür danach eine Zeit lang mehr. Aber den Tagesschnitt wirst du nicht mehr auf über 300 MBit/s bringen können. Mir fällt jedenfalls keine entsprechende Strategie ein, mit der man das erreichen könnte.

    Ok, der traceroute sieht mittlerweile gut aus...

    Code
     1. 2a0a:4cc0:c0:6000::2   
 2. 2a01:4a0:1338:77::1    
 3. 2a01:4a0:0:2015::2     
 4. 2a01:4a0:0:2003::4     
 5. 2001:1900:5:2:2::53a9  
 6. 2001:1900::3:284       
 7. (waiting for reply)

    LE und SSL Labs tun auch wieder. Hoffen wir mal, daß es so bleibt...

    Zitat von Virinum

    To keep our CA software simple we only perform an IPv6 to IPv4 retry on the first request when validating “http-01” challenges. If you use redirects, the redirects will not get retry treatment.

    Hm, ich sehe einen Request mit http über ipv4. Da ich bei den meisten vhosts https-redirect aktiv habe, könnte das tatsächlich daran liegen. Aber ich hätte erwartet, daß die redirects dann auch über ipv4 kommen (alles andere macht m.E. keinen Sinn), ist aber wohl nicht so...

    Zitat von KB19

    Ich liebäugle gerade mit einem CSS318 […]

    Tja, das war wohl leider ein Griff ins Klo. :(

    Aber nicht wegen der Software, denn das Ding passt nicht in einen 10" Wandverteiler von Triton. Mit den Montagewinkeln ist der Switch ca. 1mm zu breit. Genau so etwas wurde auch schon im Testbericht von ServeTheHome kritisiert, dass es je nach Rack sehr eng bis unmöglich werden könnte.

    EDIT: Aber das Ding gefällt mir so sehr bzw. es ist halt in diesem Preisrahmen alternativlos, dass ich jetzt eigene Montagewinkel baue. :D

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 (29. August 2025 um 15:18)

    Das ist heute auch ein interessanter Ablauf:

    1. 10:44 Meldung über Ausfall Ihres vServers (Server ist online)
    2. 12:25 Gutmeldung nach Ausfall (Server ist immer noch online)
    3. 12:33 Gutmeldung nach Ausfall (Server ist immer noch online)
    4. 12.38 Server fällt jetzt wirklich aus und ist auch im SCP nicht mehr aufrufbar (n/a)