Beiträge von SCD

Gerade nochmal in die Sperrmail geguckt

Zitat

Treshold Bandwidth: 175 MBit/s
Sum Bytes: 134.79 GByte/300s (3.59 GBit/s)

Wird hier nicht zu früh gesperrt. Mir stehen doch 5 Gbit/s zur Verfügung ?

Leider nein ...

Zitat von [netcup] Felix

Guten Tag,

eine IP-Adresse kann nicht geändert werden. Diese ist fest an den Server gebunden.

[...]

Mit freundlichen Grüßen

Felix Preuß

Alles anzeigen

Hallo,

nachdem unser Server bereits am 31.10. um 21:10 unter einem UDP Angriff Stand ging es gerade zum zweiten Mal los.

Wieder ein UDP Angriff:

Direction: IN
Destination IP: xxxx
Treshold Packets: 30000 packets/s
Sum Packets: 107429000 packets/300s (358096 packets/s)
Sum Bytes: 134.79 GByte/300s (3.59 GBit/s)




     Src IP Addr:Port          Dst IP Addr:Port  Proto  Packets    Bytes
  185.39.161.152:53    ->    xxx:4444  UDP        750    1.1 M
  185.39.161.152:53    ->    xxx:4444  UDP        750    1.1 M
     46.29.79.59:0     ->    xxx:0     UDP       2750    3.8 M
    185.171.60.2:0     ->    xxx:0     UDP       1000    1.5 M
   95.78.232.174:53    ->    xxx:4444  UDP       1000    1.5 M
  88.135.232.123:0     ->    xxx:0     UDP       3250    4.4 M
   131.100.248.1:53    ->    xxx:4444  UDP        250   375000
.
.
.

Nach zwei Minuten ist dann die zweite Mail gekommen, dass der Angriff zu groß geworden ist, und die IP gesperrt wird (obwohl die 5 GBit/s noch nicht erreicht wurden ?)

Zitat

Sum Bytes: 134.79 GByte/300s (3.59 GBit/s)

Der Server ist erst seit dem 18.10.2016 im Einsatz. Bei alten Anbieter hatten wir nie Schwierigkeiten mit DDoS.
Auf eine Supportanfrage NC#2016110610003168 ob der Angriff eventuell nicht uns gilt, sondern dem Vorbesitzer der IP können wir aus Datenschutzgründen keine Antwort bekommen.

Der Angriff ging beide Male genau 45 Minuten (bzw. die Sperrung)

Welche Möglichkeiten haben wir nun noch ?

Nicht unbedingt: https://www.netcup.de/bestellen/produkt.php?produkt=1360

Ist nur die Frage, ob man hier auch die Best-Price Garantie nutzen kann...

Hallo,

ich hole das Thema nochmal nach oben, da ich das gleiche Problem habe.

Meine /etc/network/interfaces (hier ohne IP-Adressen)

Zitat

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address
netmask 255.255.252.0
broadcast
gateway

iface eth0 inet6 static
address
netmask 64
gateway fe80::1
post-up ip -6 route add default via fe80::1 dev eth0

Alles anzeigen

Nach dem Neustart habe ich jedoch immer noch bei ip -6 route show

Zitat

default via fe80::1 dev eth0 proto ra metric 1024 expires 1653sec hoplimit 64

Nach dem ip -6 route add default via fe80::1 dev eth0 auf der Console ist alles richtig. Nur ich möchte das gerne automatisch haben.

Hallo,

trotz KVM würde ich sagen, der verlinkte Thread zählt immer noch:
Du hast nur VCores und keine dedizierte Kerne, die nur für dich da sind.

Bei dem normalen Root-Server M SSD v6 (ohne a), würde meine Meinung nach nichts dagegen sprechen.

Hallo,

bitte den Post nicht verkehrt verstehen, weil er sehr kritisch wird. Ich habe dem G6 Server M mit SSD und SLA+ und bin voll damit zufrieden.

Zitat von [netcup] Felix

Was der EX4 oder auch EX10 nicht beinhaltet ist ein DVD-Laufwerk, eine dauerhafte und kostenlose Remote-Konsole, die Möglichkeit ohne Softwareinstallation Snapshots anzufertigen, diese zu im- oder exportieren usw..

Was brauche ich davon im laufenden Betrieb. Für die Einrichtung mag ja ein DVD Laufwerk praktisch sein, aber wird dann nicht mehr benötigt.
Das gleiche gilt für die Recovery Console. Hilfreich bei der Einrichtung aber wird dann hoffentlich nicht benötigt. Wenn doch ist der Server instabil und das kann ich nicht gebrauchen. Snapshots gehen sowieso nicht, da die Festplatte angeblich zu voll (weil defragmentiert ist).

Zitat von [netcup] Felix

Dann bieten die neuen Root-Server noch 99,9% garantierte Mindestverfügbarkeit und eine sehr gute Netzanbindung, auch zur Deutschen Telekom.

Gegen der Netzanbindung kann ich nichts sagen. Die war damals (neben den Preis und der guten Kritiken) der Grund zu wechseln. Die 99,9 % habe ich mit 0,99 Aufpreis für SLA+ auch bei meinen Server.

Ich bleibe dabei, die G7 ist ein Rückschritt und Preiserhöhung.

9,99 Euro bei 12 Monaten für einen G6 M mit 150 GB SSD, 8 GB RAM, 2 dedizierte CPU Kerne wäre als G7 würdig. Die SLA 99,9 % kann dann gerne wie jetzt mit 1,99 Euro im Monat berechnet werden.

Zitat von [netcup] Felix

Wie versprochen, hier ein Benchmark vom RS 8000 in der SSD-Variante:

Entweder lese ich den Benchmark verkehrt oder der RS 8000 ist unterm Strich langsamer als ein EX4 mit Festplatte (inzwischen nicht mehr im Programm) eines Mitbewerbers:

BYTE UNIX Benchmarks (Version 5.1.3)




   System: srv1: GNU/Linux
   OS: GNU/Linux -- 2.6.32.59-grsec -- #3 SMP Thu May 10 09:17:28 CEST 2012
   Machine: x86_64 (unknown)
   Language: en_US.utf8 (charmap="UTF-8", collate="UTF-8")
   CPU 0: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6824.0 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 1: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 2: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 3: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 4: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 5: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 6: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   CPU 7: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (6822.9 bogomips)
          Hyper-Threading, x86-64, MMX, Physical Address Ext, SYSENTER/SYSEXIT, SYSCALL/SYSRET, Intel virtualization
   17:21:03 up 427 days, 21:54,  1 user,  load average: 1,18, 0,80, 0,59; runlevel 2




------------------------------------------------------------------------
Benchmark Run: Mo Mai 23 2016 17:21:03 - 17:50:34
8 CPUs in system; running 1 parallel copy of tests




Dhrystone 2 using register variables       43427246.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     4251.5 MWIPS (11.1 s, 7 samples)
Execl Throughput                               3380.1 lps   (29.5 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1506357.6 KBps  (30.1 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          428914.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       2913393.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                             3012926.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 167720.5 lps   (10.0 s, 7 samples)
Process Creation                              12801.5 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   6293.0 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   4370.5 lpm   (60.0 s, 2 samples)
System Call Overhead                        4814086.2 lps   (10.0 s, 7 samples)




System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   43427246.8   3721.3
Double-Precision Whetstone                       55.0       4251.5    773.0
Execl Throughput                                 43.0       3380.1    786.1
File Copy 1024 bufsize 2000 maxblocks          3960.0    1506357.6   3803.9
File Copy 256 bufsize 500 maxblocks            1655.0     428914.3   2591.6
File Copy 4096 bufsize 8000 maxblocks          5800.0    2913393.0   5023.1
Pipe Throughput                               12440.0    3012926.4   2422.0
Pipe-based Context Switching                   4000.0     167720.5    419.3
Process Creation                                126.0      12801.5   1016.0
Shell Scripts (1 concurrent)                     42.4       6293.0   1484.2
Shell Scripts (8 concurrent)                      6.0       4370.5   7284.2
System Call Overhead                          15000.0    4814086.2   3209.4
                                                                   ========
System Benchmarks Index Score                                        1996.4




------------------------------------------------------------------------
Benchmark Run: Mo Mai 23 2016 17:50:34 - 18:22:17
8 CPUs in system; running 8 parallel copies of tests




Dhrystone 2 using register variables      162830877.4 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    30802.3 MWIPS (9.9 s, 7 samples)
Execl Throughput                              31834.9 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks       1176153.7 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          340081.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       7943310.6 KBps  (30.0 s, 2 samples)
Pipe Throughput                            12440069.6 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                2897152.7 lps   (10.0 s, 7 samples)
Process Creation                             102977.8 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  39741.5 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   5421.5 lpm   (60.1 s, 2 samples)
System Call Overhead                       10649284.1 lps   (10.0 s, 7 samples)




System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0  162830877.4  13952.9
Double-Precision Whetstone                       55.0      30802.3   5600.4
Execl Throughput                                 43.0      31834.9   7403.5
File Copy 1024 bufsize 2000 maxblocks          3960.0    1176153.7   2970.1
File Copy 256 bufsize 500 maxblocks            1655.0     340081.3   2054.9
File Copy 4096 bufsize 8000 maxblocks          5800.0    7943310.6  13695.4
Pipe Throughput                               12440.0   12440069.6  10000.1
Pipe-based Context Switching                   4000.0    2897152.7   7242.9
Process Creation                                126.0     102977.8   8172.8
Shell Scripts (1 concurrent)                     42.4      39741.5   9373.0
Shell Scripts (8 concurrent)                      6.0       5421.5   9035.8
System Call Overhead                          15000.0   10649284.1   7099.5
                                                                   ========
System Benchmarks Index Score                                        7128.3

Bei der Festplatte ist er natürlich langsamer:

hdparm -tT /dev/sda




/dev/sda:
 Timing cached reads:   23934 MB in  2.00 seconds = 11979.33 MB/sec
 Timing buffered disk reads: 440 MB in  3.01 seconds = 146.12 MB/sec




 hdparm -tT --direct /dev/sda




/dev/sda:
 Timing O_DIRECT cached reads:   562 MB in  2.00 seconds = 280.66 MB/sec
 Timing O_DIRECT disk reads: 314 MB in  3.01 seconds = 104.33 MB/sec

Vielen Dank. Der Traceroute sieht nun viel besser aus

Zitat

1 * * *
2 be10-101.gra-g1-a9.fr.eu (2001:41d0::1eb) 0.861 ms 1.082 ms 2.081 ms
3 * * *
4 gw6-decix.ffm.netcup.net (2001:7f8::3:3a4:0:1) 14.554 ms 14.538 ms 14.513 ms
5 (mein Server)

Nur schade, dass mein Ticket scheinbar nicht richtig gelesen wurde

Hallo,

ich besitze eine kleinen Server beim großen französischen Serveranbieter. Dieser wird als Backup-Server und Monitoring von meinem Netcup-Server genutzt.
Sporadisch bekomme ich von diesem Meldungen, dass mein Netcup-Server über IPv6 nicht erreichbar ist.

Der Traceroute sieht dann wie folgt aus:

Zitat

1 * * *
2 be10-101.gra-g1-a9.fr.eu (2001:41d0::1eb) 0.702 ms 0.941 ms 1.144 ms
3 be100-1199.fra-1-a9.de.eu (2001:41d0::299) 9.362 ms 9.345 ms 9.328 ms
4 decix2-gw.hetzner.de (2001:7f8::616c:0:2) 9.089 ms 9.112 ms 9.095 ms
5 core12.hetzner.de (2a01:4f8:0:3::f6) 22.072 ms 22.093 ms 22.088 ms
6 juniper1.rz2.hetzner.de (2a01:4f8:0:3::be) 11.985 ms 12.168 ms 11.959 ms
7 * * *
8 * * *
9 * * *
10 * * *

Alles anzeigen

Auffällig hierbei ist das Routing über Hetzner.

Vom Support NC#2016051810003835 habe ich die Rückmeldung bekommen, dass ich den Server im Rettungssystem fahren soll und dann nochmal testen. Da der Ausfall aber immer nur ein paar Minuten ist, ist mir dies nicht möglich. Glaube auch nicht, dass es an meinem Server liegt.

Zum Vergleich das Routing, wenn der Server erreichbar ist:

Zitat

1 * * *
2 be10-101.gra-g1-a9.fr.eu (2001:41d0::1eb) 1.677 ms 2.230 ms 2.072 ms
3 be100-1199.fra-1-a9.de.eu (2001:41d0::299) 8.900 ms 8.848 ms 9.330 ms
4 decix2-gw.hetzner.de (2001:7f8::616c:0:2) 9.127 ms 9.110 ms 9.085 ms
5 core11.hetzner.de (2a01:4f8:0:3::1e) 12.043 ms core12.hetzner.de (2a01:4f8:0:3::f6) 11.992 ms 12.109 ms
6 juniper2.rz2.hetzner.de (2a01:4f8:0:3::3a) 12.266 ms juniper1.rz2.hetzner.de (2a01:4f8:0:3::2e) 12.150 ms juniper1.rz2.hetzner.de (2a01:4f8:0:3::be) 12.192 ms
7 gw6-hetzner2.nbg.netcup.net (2a01:4f8:0:e060::6) 23.781 ms 23.730 ms 17.530 ms
8 (mein Server)

Alles anzeigen

Hat einer eine Idee, wie ich weiter vorgehen kann (der Support vom französischen Anbieter wird darauf nicht reagieren, weil mein Server ohne SLA vermietet wird)

Stefan

Habe nun den Fehler gefunden:
Der Server hat die Default-Route verloren (ip -6 route add default via fe80::1 dev eth0)

Wie konnte das passieren? Bisher war das noch nie der Fall.
Auf das Ticket kam nur die Antwort

Zitat

Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

Bei mir ist etwa 30 Minuten nach dem Neustart die IPv6 Anbindung abgebrochen.
Kann dies mit dem Fix zu tun haben. Habe vorher nie Probleme mit gehabt - Ticket ist auch schon erstellt

Zitat von Dragon

Nein, Speedtest.net gibt immer MBit/s aus.

Genau deshalb muß ja der Wert durch acht geteilt werden - Damit aus MegaBit MegaByte wird (1 byte = 8 bits)

Morgen,

Zitat von [netcup] Felix

was ich mich gerade frage ist, warum im Speedtest Vodafone als Provider genannt wird. Wurde eventuell das falsche Ziel getestet?

Dieser Speedtest ist für die eigene Bandbreite da.

Der Kunde verwechselt einfach Mbit/s mit MegaByte/s.

@MJ teile dem Wert vom Speedtest durch acht, dann kommst Du auf 265 KB/s.
Dein Internet-Provider (Vodafone) ist also das Problem. DSL ist aber immer langsamer im Upload (Richtung Server) als im Download (zu Dir nach Hause)

Morgen,

ich hätte gerne eine ...

Stefan

Hallo,

ich bin erst seit kurzem Kunde. Mir ist die Drosselung durch den Support genannt worden (ich hätte es sonst übersehen), jedoch habe ich auch auf Nachfrage keine Minutenangabe bekommen, wie lange die Drosselung besteht und auf welche Wert ich gesetzt werde

Da ich den Wert maximal in Nacht erreiche (Backup-Zeit zum anderen System - jedoch nur rsync) wird mich diese auch nicht stören, es seih denn, sie wird dann permanent.

Dazu hätte ich habe auch gerne eine Aussage:

Ist die Drosselung nun permanent oder nur für einen begrenzten Zeitraum (dann wie lange)

Stefan