Netzwerkperformance

[Eye-Q]

Mahlzeit,

bei einem Kunden wird das Klasse-C-Subnetz, was am Hauptstandort läuft, zu klein, so dass wir gerade planen, die IP-Adressen umzustellen. Außerdem ist die Adressrange sowieso ungünstig (192.1.1.0/24, historisch bedingt, ich weiß dass da Müll ist), so dass auf jeden Fall alles umgestellt werden wird, egal auf welchen Adresskreis. Mehr als 2000 IP-Adressen werden jedoch nicht benötigt, im Moment ist das natürlich auf 254 IP-Adressen beschränkt.

Ich habe vorgeschlagen, einfach ein normales privates Klasse-B-Subnetz (172.16.0.0/16) einzurichten, natürlich mit viel Vorplanung, Checklisten und doppelter und dreifacher Kontrolle.

Mein Kollege meint, dass es evtl. besser sei, zwar Klasse-B-Adressen, aber als Subnetzmaske z.B. /22 zu nehmen, damit die Broadcast-Domäne nicht so groß ist.

Mein Gegenargument ist, dass die Verwaltung eines künstlich verkleinerten Subnetzes schwieriger ist. Grund: wenn man z.B. bei einem Windows Server eine statische IP-Adresse einrichtet und dort beispielsweise die 172.16.0.100 eingibt, füllt Windows automatisch die Subnetzmaske mit 255.255.0.0 aus, womit man dann bei einem /16er-Subnetz die Subnetzmaske nicht mehr anpassen muss. Darauf muss man bei einer /22er-Subnetzmaske immer achten.

Gibt es noch weitere Argumente Pro/Contra /16 bzw. /22-Subnetzmaske in einem privaten Netzwerk, die ich vielleicht übersehe?

 

Vielen Dank im Voraus

[Crash2001]

Also dass die Subnetz-Maske standardmäßig anders vorgegeben wird, würde ich jetzt nicht unbedingt als Contra-Argument anführen. An so vielen Stellen muss man die Subnetz-Maske auch nicht wirklich eintragen. Gut - eine /22er Maske würde ich nicht unbedingt nehmen, sondern dann eher /24er Netze.

Ich kann nur sagen, dass man Netze so klein wie möglich und so groß wie nötig halten sollte, damit im Problemfall nicht alle Rechner betroffen sind, sondern nur ein bestimmter Bereich.

Sagen wir mal einfach jemand steckt einen Loop - da kann es zu Broadcast Storms, falschen Zuordnungen von MAC-Adressen zu Switch Ports (Probleme mit Authentifizierungsverfahren, da die MAC-Adresse auf einem anderen Port zu sehen ist und eine Authentifizierung am richtigen Port blockiert) und diversen anderen Problemen kommen, die das Segment de facto lahm legen. Je kleiner das Segment ist, um so weniger Geräte sind betroffen => kleinerer Impact.
Nicht ohne Grund wird bei großen Firmen oftmals eine Layer-3-Abkopplung der Client-Netze gemacht. Genau aus dem Grund, dass Beeinträchtigungen in einem Netzsegment nicht das komplette Netz mit runterziehen, sondern wenn nur das eine Segment.

Solange es keinen sinnvollen logischen Grund gibt, dass alle IP-Adressen im selben Subnetz sind, würde ich diese somit z.B. in /24er Netze aufteilen nach z.B. Abteilungen, Gebäuden, Stockwerken, benötigten Berechtigungen oder sonstigen logischen Kriterien. So kann man auf einer Firewall auf die Regeln viel restriktiver festlegen und Clients, die spezielle Berechtigungen brauchen z.B. in ein campusweites Sondernetz legen mit festen IP-MAC-Adressen-Zuordnungen und Sonderregeln für die jeweilige IP-Adresse.

Ja, man hat etwas mehr Arbeit mit der Verwaltung von dann sagen wir einfach mal 10-15 Netzen statt einem großen, aber man fährt damit einiges sicherer. Viele Probleme kommen nicht über die Subnetzgrenzen hinaus (z.B. jegliche Probleme mit Broadcasts) und je größer ein Netz ist, um so höher wird auch der Anteil an Broadcast Traffic und um so schwerer die Auswirkungen z.B. bei einem Loop. Genauso blockiert der Broadcast-Anteil im Netz jedoch Bandbreite und bremst die Anbindung aus ab einem bestimmten Prozentsatz, da alle Rechner auch jeglichen unnötigen Traffic (z.B. Anfrage nach DHCP-Server) mitbekommen.

Nachtrag:
Ich würde eh überlegen, ob ich einem Server statisch eine IP-Adresse geben würde (Ausnahme vielleicht AD oder noch ein oder zwei andere grundlegend wichtige Server), oder ob ich sie ihm statisch per MDHCP-Eintrag zuweisen lassen würde vom DHCP-Server.
Bei statischen IP-Adressen muss man diese in einer Liste pflegen, die immer aktuell sein sollte, damit man keine IP-Adresskonflikte hat. Regelt man dies über den DHCP-Server, so kann man IP-Adressen nicht doppelt vergeben und hat zudem auch noch den Komfort, dass wenn sich irgendetwas ändert (z.B. IP-Adresse des DNS-Servers oder des Gateways) man dies per DHCP mitgeben kann und somit nicht überall händisch eintragen muss.

 

Bearbeitet 15. Dezember 2015 von Crash2001
nachtrag hinzugefügt