[Anexia] Theo V. Ich hatte euch die Tage schonmal ans NOC gemailt, von meinem Netcup-Server kam ich nicht per IPv6 zu AS56382, da war's nach dem AMSIX tot. v4 dagegen lief problemlos. Momentan rejected AS56382 euch am AMSIX deswegen und läuft über Transit.
Beiträge von bjo
-
-
Das glaube ich nicht. Netcup hat 2010/2011 ein altes Het zner Rechenzentrum gekauft oder übernommen (komplett gepachtet) und 2016 wurde Netcup gekauft und jetzt gehört das RZ vermutlich Anexia und nicht mehr dem Tochterunternehmen Netcup und Netcup "mietet" nun einen Teil und die Verwaltung sowie der nicht von Netcup verwendete Teil hängt bei Anexia und Netcup kann schreiben "Wir können dazu keine Aussage treffen, sind nur Mieter"

(alles nur Spekulation)
Ok, auch möglich
Jedenfalls steht überall nur "direkte Verbindung zur Feuerwehr" und nichts von Gas-Löschanlagen. -
NC hat, wie der Support oben ja schreibt, sich zu größeren Teilen in einem RZ eingemietet, dessen Beschreibung des Brandschutzes sich mit der von dir zitierten Beschreibung deckt.
Insgesamt mag man sich aber fragen, inwieweit bei einem "klassischen Rechenzentrumsaufbau" eine ähliche Brandausbreitung wäre im Vergleich zu dem selbstbelüfteten Tower in SBG.
@mainzimann:
Octave sagte im Video gestern, dass vermutlich der Brand von einer USV ausging, die vorher am Morgen gewartet worden war.
-
Zum Glück hostet ein Anbieter, bei dem man per borg Backups hinschieben kann, in Falkenstein und nun in Helsinki. Sprich: gute Anbindung von NC aus gegeben und wenn die Nachbarn im RZ anfangen zu kokeln, wären die Daten sicher.
Ich hatte kurzfristig mal überlegt, stattdessen die Backups selbst auf NFS zu lagern, aber der Vorfall in SBG zeigt doch, wie wichtig Offsite Backups sind.
-
Ich habe das Problem mit meinem G9 1000 mit Arch und LTS-Kernel (5.4.x) auch. Zum Glück keine Reboots, aber ab und an BUG: soft lockup - CPU#0 stuck for 31s
-
Das ist alles ein Schmerz mit denen. Ich habe letzten Monat 2 Server umgezogen, die Domains gibt es auch schon lange, Mails werden DKIM signiert, SPF gesetzt. Beide sind im 45.129.180.0/22, einer der beiden wird beim Versand an outlook.de etc, geblocked, jedoch nicht an irgendwelche O365-Tenants oder so.
Auf der Mailingliste, auf denen diese Probleme oftmals thematisiert werden, zeigt sich aber, dass das /22 nicht das einzige Netz ist, bei dem sich Microsoft so verhält:
-
Debian works? Hauptsache anders gemacht als Upstream es vorsieht.
-
Aber alternativ könnte man sich auch ein VXLAN bauen? Oder erzeugt das dann auch schon zuviel Latenz? Ich nutze VXLAN bisher nur zwischen wirklich unterschiedlichen RZ-Standorten.
-
@cljk: Du musst halt mal fstrim ausführen. Klitzekleines Problem bei proxmox: Das klappt für fast alles außer in den lxc-Containern.
fstrim läuft bei mir jede Woche, trotzdem rödelt die Speicheroptimierung nun seit einigen Minuten.
-
Guten Morgen,
Langfristig schließen wir einen Wechsel auf AMD Epyc CPUs nicht aus. Diese werden intensiv von uns getestet. Wenn wir zu AMD schwenken, geschieht dieses mit einer neuen Root-Server Generation. Die vorangegangene Generation wird dann weiterhin bestellbar sein, so dass Sie als Kunden wählen können ob Sie eine CPU von Intel oder AMD nutzen möchten.Da bin ich mal gespannt. Mein Arbeitgeber hat neulich mal Angebote für einen Kundenserver basierend auf den Epycs eingeholt und das sah vom Preis-Leistungsverhältnis sehr interessant aus.
-
Gibts Baikal nicht mehr? Das war doch afaik auf PHP basierend.
-
Ja bringt aber nichts, da die Ip des Servers ja gesperrt ist nicht die Domain.
Das dachte ich ja auch, mit der anderen Domain konnte ich aber Problemlos senden, IP/Hostname/PTR vom Server war gleich geblieben. Absendedomain wieder geändert und es gab og. Fehlermeldung.
-
Hast du noch eine andere Domain von der du versenden könntest?
-
Es wird noch kurioser: Verwende ich eine 10 Jahre org-Domain als Absende-Domain, geht die Mail durch. Mit einer zwei Tage alten .email-Domain nicht. Dann passt die Fehlermeldung ja kein Stück.
-
Aber hallo.
Da schickt man ihnen
Code<hans.user@outlook.de>: host eur.olc.protection.outlook.com[104.47.2.33] said: 550 5.7.1 Unfortunately, messages from [194.59.205.xy] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). You can also refer your provider to http://mail.live.com/mail/troubleshooting.aspx#errors. [DB5EUR01FT023.eop-EUR01.prod.protection.outlook.com] (in reply to MAIL FROM command)und kriegt diesen *$%$ als Antwort:
ZitatI do not see anything offhand that would be preventing your mail from reaching our customers.
You may be able to find additional information on common delivery questions at the Outlook.com Postmaster Site found at https://mail.live.com/mail/postmaster.aspx I would like to highlight some key areas that I believe are appropriate to your company.
-
Oah, diese Flitzpiepen.
ZitatWe have completed reviewing the IP(s) you submitted. The following table contains the results of our investigation.
More information needed
194.59.205.xx/32
We were unable to identify anything on our side that would prevent your mail from reaching Outlook.com customers.
Ja, wenn sie gleich das /22 blocken, dann finden sie die auch nicht.
-
Achja, das ewige Leid mit Microsoft und Konsorten. Auf der mailop-Mailingliste war nun auch ein Fall, wo jemand bei SDNS und dem ganze Geraffel angemeldet war und trotzdem seine Mails geblockt werden. Zugleich liest man dann von Fällen, wo Amazon's abuse-Adressen mit "user unknown" bouncen.
-
Wie sieht es mit Yahoo und GMX aus? Dort hatte ich Probleme …
Mit Shared Webhosting oder eigenem Server?
-
Danke für deine Erläuterungen!
-
Es wird dem darunterliegendem Storage mitgeteilt, dass der Block anderweitig beschrieben werden kann.
Mitlerweile gibt es ja zwei Defragmentierungsbegriffe bei Netcup.
Also ist der Speicherplatz nicht "fest" allokiert wie beispielsweise wenn man einer VM ein LV zuweisen würde?
Worin unterscheiden sich die beiden Defragmentierungsbegriffe?