Das längste Thema

Jetzt würde ich aber den Vermieter anrufen!

jetzt mal eine Frage unter denen die im eigen LAN bereits ebenfalls IPv6 verwenden;

am Beispiel vom Prefix: 2001:db8:1234::/48

wenn man per stateful DHCPv6 Adressen verteilt

z.B. 2001:db8:1234:5678:0:0:0:0 bis 2001:db8:1234:5678:ffff:ffff:ffff:ffff,

dann hat man am Client z.B. 2001:db8:1234:5678:4711:cafe:affe:1010/128

welche Prefixlänge würde man vergeben, wenn z.B. 2001:db8:1234::100 für einen Host fix vergibt?

auch 128 od. 48 od. gleich den Standardwert von 64?

bei Windows bin ich auf eine seltsame Erkenntnis gekommen; hier ist die Standardfirewall so eingestellt,

dass bei der Firewallregel f. 'File and Printer Sharing (SMB-In)' bei Remote IP address

'Local subnet' angeführt ist; und dies bezieht sich auf den Prefix;

soll heißen, will man auf diesen Rechner zugreifen, dann muss der andere Host

sich innerhalb des Prefixes vom Rechner befinden; will man dass das gesamte LAN darauf zugreifen kann,

vergibt man als Prefixlänge in diesem Beispiel 48;

würde man die IPv6 von einem DHCP bekommen, dann hätte man hier als Pretix ebenfalls die 128 und

kein Zugriff ist mit dieser Standardregel möglich;

(auf das muss man mal kommen)

mainziman Wieso sollte es /128 sein? Eigentlich weiterhin immer /64, außer Du willst Dir Probleme einhandeln…

# DHCPv6
    inet6 fdxx:xxxx:xxxx:xx::zz/64 scope global
       valid_lft forever preferred_lft forever

# SLAAC
    inet6 fdxx:xxxx:xxxx:xx:yyyy:yyyy:yyyy:yyyy/64 scope global dynamic
       valid_lft forever preferred_lft forever

So sieht das auf einem (Linux) Gerät aus, das sich zwei Adressen holt.

Natürlich könntest Du einzelne Adressen zusätzlich als /128 hinzufügen. Aber irgendwas sollte halt schon auf das /64 hinweisen, sofern das Deine verwendete Präfixlänge ist.

Ich mach das bei mir bei IPv4 und IPv6 gleich, 192.168.4.0/22 ist das IPv4-Subnetz, per DHCP bekommt der Rechner z.B. 192.168.4.62/22. Bei IPv6 ist es 2001:db8:1234:5678::/62 und der Rechner bekommt die 2001:db8:1234:5678::abc/62.

EDIT: Muss mich korrigieren, die per SLAAC konfigurierten Adressen haben die Prefixlänge 62, die mit DHCPv6 konfigurierten haben Prefixlänge 128. In den Routen (ip -6 route) sehe ich aber, dass darin alles wie erwartet gesetzt ist.

Spielt die Subnetzmaske / Prefixlänge in der Ausgabe ip adress überhaupt eine große Rolle?

Macht es denn Sinn die dem nächsten Router bekannte Subnetzgröße bei den Endgeräten anders zu konfigurieren? Damit macht man sich doch nur selbst Probleme, wenn Pakete dann ihr Ziel nicht finden, weil der Rechner meint das Subnetz sei größer bzw. kleiner.

femur /62? Kein Vertipper?

Da würde ich definitiv nur ein /64 daraus verwenden. Macht ja irgendwie keinen Sinn ein ganzes /62 weiterzuverteilen. Lieber 3×/64 für andere Spielereien in Reserve haben

Hab hier ein /56 vom Provider (Vodafone-Kabel), das LAN bekommt ein /62 damit ich für Spielereien (VM/Container) an meinem Rechner Subnetze bilden kann. Zugegebenermaßen habe ich das bisher nur einmal wirklich verwendet..

Wäre es da nicht sinnvoller ein weiteres Subnetz beliebiger Größe dorthin zu routen, als das ganze LAN zu vergrößern?

Oder willst Du die explizit im gleichen (großen) Subnetz haben?

Quote from martin\

Jetzt würde ich aber den Vermieter anrufen!

Die einzige Lösung, die man optisch halbwegs verkaufen könnte, würde 70 Meter Kabel quer durchs Haus bedeuten. Von daher: Njet

Quote from KB19

Die einzige Lösung, die man optisch halbwegs verkaufen könnte, würde 70 Meter Kabel quer durchs Haus bedeuten...

Oder ganz nach oben ziehen.

DLAN und los

Quote from KB19

Noch komplizierter und auch schnell teuer.

Kommt auf deine Beziehungen zur Aufzugsfirma an.

Wenn deine Wohnung an den Schacht grenzt, ist das dann genau ein 5mm Loch.

Der Schacht hat gar keine Wände, ist komplett einsehbar und rundherum verläuft das Stiegenhaus.

Quote from KB19

Der Schacht hat gar keine Wände

Blöder neumodischer Kram.

Quote from KB19

mainziman Wieso sollte es /128 sein?

weil ich es mit einem Linux wo ich auf DHCP gestellt hab es getestet hab und dort war dann prefixlen 128 zu sehen;

genau das macht mich ja irgendwie stutzig, wie sehe ich bei windows was er als prefixlen 'genommen' hat?

mein dhcpd6.conf sieht so aus:

ddns-updates off;

allow client-updates;

authoritative;

# time twice as leases lasts half-time
default-lease-time 7200;

max-lease-time 86400;

allow leasequery;

default-lease-time 3600;
max-lease-time 86400;

dhcpv6-lease-file-name "/var/lib/dhcpd/dhcpd6.leases";

subnet6 2001:db8:cafe:db00::/56 {
        range6 2001:db8:cafe:db7f:0:0:0:0 2001:db8:cafe:db7f:ffff:ffff:ffff:ffff;
        range6 2001:db8:cafe:db7f::/64 temporary;

        option dhcp6.name-servers 2001:db8:cafe:db00::1, 2001:db8:cafe:db00::17;
        option dhcp6.domain-search "localdomain";

        option dhcp6.info-refresh-time 600;

        option dhcp6.preference 255;
}

Quote from mainziman

bei Windows bin ich auf eine seltsame Erkenntnis gekommen; hier ist die Standardfirewall so eingestellt,

dass bei der Firewallregel f. 'File and Printer Sharing (SMB-In)' bei Remote IP address

'Local subnet' angeführt ist; und dies bezieht sich auf den Prefix;

soll heißen, will man auf diesen Rechner zugreifen, dann muss der andere Host

sich innerhalb des Prefixes vom Rechner befinden; will man dass das gesamte LAN darauf zugreifen kann,

vergibt man als Prefixlänge in diesem Beispiel 48;

Display More

Da ist schon der Fehler. Innerhalb eines LANs sollte es niemals Prefixes kürzer als /64 geben. Wenn man ein kürzeres Prefix hat, sollte man sich /64 Netze daraus machen, die man an gegebener Stelle einsetzt. Aber innerhalb eines LANs, wo die Geräte unmittelbar miteinander kommunizieren sollen (z.B. für den Zugriff auf Drucker/SMB), vergibt man dann natürlich nur Adressen aus einem /64 Netz.

Ich bin auch nicht Glücklich mit der Verhaftung auf /64, z.B. für SLAAC. Aber es führt nun mal dazu, dass viele Geräte mit anderen Prefix Längen nicht zurecht kommen (auch Drucker etc.). Deshalb: Ein LAN IMMER mit /64 planen und die Infrastruktur (RADVD, DHCPv6) darauf ausrichten. Wenn dann 65534 Subnetze eines /48 ungenutzt bleiben, dann ist das halt so.

frank_m 'nicht Glücklch' hast schön gesagt;

interessant wie KB19 es geschafft hat, bei mir hat ein Linux das vom DHCP sich 'genommen'

eine Trennung, auch wenn es nur eine logische ist, darf schon sein auch bei IPv6, denk ich mal;

(bei IPv4 habe ich ein großes /16-Netz, und bei DHCP habe ich mir nur ein /24 rausgepickt;)

Ich bin gerade sehr... erstaunt. Mein VPS Ostern B 2017 HDD mit

Quote

Festplatte: 100 GB SATA (RAID1)

Arbeitsspeicher DDR 3 ECC: 512 MB

Prozessorkerne: 2 virtuell

Prozessor: Intel® Dual-Core

muss auf einen potenteren Host mit möglicherweise anderer (neuer?) Hardware verschoben wurden sein. Er hatte bisher immer in der Tabelle von m_ueberall den letzten Platz belegt und war selbst bei einem stinknormalen apt update mehrere Minuten beschäftigt. Bei einem mkdir konnte man paar Sekunden zuschauen wie der Befehl ausgeführt wurde. Ich kann mir kaum vorstellen, dass der extreme Geschwindigkeitsschub nur durch weniger Nachbarn entstanden sein soll.

Ich muss gestehen, dass ich für eine ganze Weile vollkommen die Existenz der Maschine vergessen habe. Paar hundert Tage Uptime, kein Dienst oder irgendwas drauf, nur Firewall an. Heute bin ich drauf, hab Updates durchgeführt (90 Stück waren offen), mal einen Reboot durchgeführt... und dann ist mir aufgefallen wie schnell das eigentlich ging. Ich musste sofort 3x prüfen, dass ich nicht die Produkte vertausche oder so, aber hier die Ergebnisse:

Der Support hat mir damals auch versichert, dass das bei einem Preis von 99ct halt so langsam ist. Hab ich auch akzeptiert, aber ich bin ja plötzlich auf einem anderen Planeten Existiert dein RS X-Mas 2016 2 (HDD) noch m_ueberall ? Der hatte laut Tabelle ähnlich schlechte Werte.

Quote from Valkyrie

Existiert dein RS X-Mas 2016 2 (HDD) noch m_ueberall ? Der hatte laut Tabelle ähnlich schlechte Werte.

Den habe ich inzwischen an einen anderen Kunden abgetreten. Hoffe meinerseits dann aber auf baldige Verschiebung meiner G8-HDD-RS…

PS: Valkyrie – Du möchtest mir den VPS schenken, nicht wahr? hypno.gif

Den Kleinen, kann ich auch gut gebrauchen.

Quote from Valkyrie

Existiert dein RS X-Mas 2016 2 (HDD) noch m_ueberall ? Der hatte laut Tabelle ähnlich schlechte Werte.

Ich verwende einen davon produktiv, da merke ich keine extremen negativen Effekte. Klar, die HDD ist nicht schnell und das merkt man auch, aber er tut was er soll ohne überdurchschnittliche Wartezeiten.

Das System war somit definitiv beschäftigt, da komme ich bei einem kurzen Test (ext4) auf solche Werte:

test1: (groupid=0, jobs=1): err= 0: pid=23875: Thu Dec 16 17:20:22 2021
  read: IOPS=243, BW=974KiB/s (997kB/s)(119MiB/125065msec)
   bw (  KiB/s): min=  112, max= 1928, per=99.94%, avg=972.46, stdev=275.96, samples=250
   iops        : min=   28, max=  482, avg=243.08, stdev=68.99, samples=250
  write: IOPS=81, BW=325KiB/s (333kB/s)(39.7MiB/125065msec); 0 zone resets
   bw (  KiB/s): min=   40, max=  672, per=99.94%, avg=324.80, stdev=98.27, samples=250
   iops        : min=   10, max=  168, avg=81.15, stdev=24.56, samples=250
  cpu          : usr=0.43%, sys=1.25%, ctx=17716, majf=1, minf=9
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=99.8%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued rwts: total=30445,10167,0,0 short=0,0,0,0 dropped=0,0,0,0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Bei meinem zweiten RS X-Mas 2016, den ich noch nicht so lange habe, komme ich auf folgende Werte. Der hat aktuell nichts zu tun, getestet im Rettungssystem mit einem neu erstellten ext4 auf der HDD:

test1: (groupid=0, jobs=1): err= 0: pid=2529: Thu Dec 16 16:25:04 2021
  read : io=476212KB, bw=567520B/s, iops=138, runt=859248msec
  write: io=158492KB, bw=188881B/s, iops=46, runt=859248msec
  cpu          : usr=0.26%, sys=1.04%, ctx=120543, majf=0, minf=7
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, >=64=100.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.1%, >=64=0.0%
     issued    : total=r=119053/w=39623/d=0, short=r=0/w=0/d=0, drop=r=0/w=0/d=0
     latency   : target=0, window=0, percentile=100.00%, depth=64

Beide Server haben folgende CPU: Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz

Wirklich spürbar lahm war eigentlich nur irgendein Osterangebot vor ≥5 Jahren, das müsste der Ostern 2015 Root-Server ES gewesen sein.