Archiv für den Monat November 2010

Classless Inter-Domain Routing – Teil 2

Nachdem ich im ersten Teil auf die Theorie eingegangen bin, kommen wir jetzt auf die Konzeption und Planung zu sprechen: Der erste Schritt vor der Planung ist zunächst einmal ein Proof of Concept, um die Idee des CIDR zu validieren.

Deshalb setzten wir zunächst einmal eine kleine Testumgebung samt einem Domain Controller auf. Bei uns waren es zwei Server, wobei einer die Rolle des DC innehatte, sowie 3 Clients, davon 2 virtuell. Die Clients erhielten per DHCP ihre IP vom DC, der zweite Server hatte eine feste Adresse. Außerdem lief auf dem zweiten Server eine kleine Serversoftware, auf welche von den Clients zugriffen wurde (beispielsweise könnte man hier einen FTP Server aufsetzen). Das Einrichten der Testumgebung ist der anspruchsvollste Teil. Danach ändert man lediglich an den zwei Servern manuell die Subnetzmaske. Darüber hinaus muss man auf dem DC noch prüfen, ob dieser per DHCP auch die richtige Subnetzmaske verteilt. Im Anschluss funktionierte alles weiterhin wie gewohnt. Demzufolge hatten wir im kleinen Rahmen sichergestellt, dass der Gedanke zur Vergrößerung unseres Netzes durchaus funktionieren kann.

Um zumindest ein gewisses Maß an Sicherheit über das geplante Vorhaben zu bekommen, recherchierten wir im Internet noch über etwaige bekannte Probleme. Da es hier stark davon abhängt, wie die eigene Infrastruktur aussieht, will ich nicht näher auf die Funde eingehen. Lediglich folgendes sei angemerkt: Einige alte Protokolle können hier durchaus Probleme haben. Außerdem stießen wir auf Einzelfälle, die über Schwierigkeiten beim VPN Zugriff berichteten. Diesen Punkt schrieben wir auf unsere Liste.

Abgesichert durch unseren Test und die Recherche, gingen wir zur detaillierten Planung über. Wir begannen mit einer Bestandsaufnahme, d.h. welche Geräte hängen alle am Netzwerk, wie sind sie angeschlossen und – was oft vergessen wird – funktionieren diese überhaupt. In der Regel ist es so, dass der verfügbare Adressbereich des eigenen Netzes (bei uns 192.168.115.0 bis 192.168.115.256) in zwei Segmente aufgeteilt wird: Den DHCP Bereich, aus dem der Domain Controller IPs an die Clients verteilt, und den festen Adressbereich, der vorwiegend für Server, aber auch diverse Peripherie verwendet wird. Während das DHCP Segment keinerlei Vorüberprüfung bedarf, sieht die Sache bei den festen IPs anders aus. Wir nahmen unseren bereits existierenden Netzwerkplan (den es hoffentlich in jeder Firma gibt), auf dem neben den Servern auch alle sonstigen, ans Netzwerk angeschlossenen Geräte vermerkt sind, darunter Drucker, Faxe, Scanner, Multifunktionsgeräte, Audio Codes, Webcams, Printserver und viele mehr (z.B. die Alarmanlage!). Bei der Überprüfung kam heraus, dass der Plan lediglich zwei falsche Geräte auswies, die drei Tage vorher gegen neuere getauscht wurden. Ich selbst würde dies als durchaus guten Wert bezeichnen, wenn man bedenkt wie viele Geräte wir haben und wie oft welche getauscht werden. Danach nutzten wir einen klassischen Netzwerkscanner, um erstens zu prüfen, ob wir irgendwelche Peripherie aus dunklen Kämmerchen vergessen hatten, und zweitens, um auch sicherzustellen, dass die Hardware überhaupt funktionierte. Das Ergebnis des Ping-Tests haben wir uns für einen späteren Vergleich abgespeichert. Zu guter Letzt prüften wir noch, ob wir auf alle gefundenen Geräte Zugriff hatten (z.B. über das Webinterface eines Audio Codes) und ob es dort auch möglich war die Netzwerkeinstellung zu ändern. Dabei stellten wir fest, dass wir von zwei Druckern keine Zugangsdaten hatten. Diese waren durch das Handbuch schnell gefunden.

Hier nochmal zusammengefasst, welche Punkte wir bereits abgehandelt haben:

1. Proof of Concept

2. Recherche bzgl. bekannter Probleme

3. Bestandsaufnahme / Analyse der Ausgangssituation

In Teil 3 gehen wir dann auf die konkrete Umstellung ein.

Classless Inter-Domain Routing–Teil 1

Wie viele kleine und mittelständische Firmen haben bzw. hatten wir ein sogenanntes Klasse C Netzwerk. Dabei ist die Subnetzmaske immer die 255.255.255.0 und die IP Adresse gestaltet sich in der Form 192.168.*.*. Dabei muss bei allen ans Netz angeschlossenen Geräten die dritte Stelle gleich sein, z.B. ist das bei uns die 192.168.115.*. Jede IP eines bei uns angeschlossenen Gerätes fängt mir diesen Zahlen an. Das liegt darin begründet, dass die Subnetzmaske an den ersten 3 Stellen die 255 steht. Für eine erfolgreiche Kommunikation zwischen zwei Rechnern müssen die Binärdarstellungen der zwei IP Adressen an den durch die Subnetzmaske festgelegten Stellen übereinstimmen. Damit sind sie “in einem Netz”. Folgendes Beispiel anhand von 3 Rechnern soll dies verdeutlichen:

192.168.115.2 11000000 10101000 01110011 00000020
192.168.115.12 11000000 10101000 01110011 00001100
192.168.116.2 11111111 11111111 01110100 00000020
255.255.255.0 11111111 11111111 11111111 00000000

 

Überall, wo die Subnetzmaske in der Binärdarstellung eine 1 aufweist, müssen die IP Adressen den gleichen Binärwert haben. Während dies bei den ersten zwei Adressen 192.168.115.2 und 192.168.115.12 der Fall ist, trifft das bei 192.168.116.2 nicht zu. Damit können nur die zwei ersten Gerät miteinander kommunizieren.

Da uns nun durch den starken Anstieg und vor allem durch VoIP-basierten Telefonen die freien Adressen im 115er-Bereich ausgegangen sind (theoretisch 256 Adressen, davon 254 effektiv nutzbar), mussten wir unser Netz umstellen. Neben der Möglichkeit auf sogenannte Klasse A oder B Netze umzusteigen, wäre es darüber hinaus auch möglich gewesen auf IPv6 zu setzen. Auf diese Lösungen will ich aber an dieser Stelle nicht eingehen, da wir möglichst schnell und einfach ohne große Umstellungen unser Netz vergrößern wollten. Wenn man sich das oben genannte Beispiel anschaut, geht dies am einfachsten, wenn die Subnetzmaske geändert wird, da die IP Adressen dann gleich bleiben können. Das ist in Anbetracht der Tatsache, dass vielleicht in altem Programmcode, in diversen Skriptlösungen oder gar in Teilen der Systemlandschaft noch anhand der IP Adresse zugegriffen wird, sicherlich von Vorteil. Denn obwohl heutzutage die meisten Client-Server-Netze auf DHCP setzen, sind zumindest noch die Server und diverse Peripherie (Printserver, Multifunktionsgeräte, Audio Codes, etc.) meisten mit festen Adressen ausgestattet. Aus diesem Grund entschieden wir uns dafür, die Subnetzmaske zu ändern, was dem Konzept des Classless Inter-Domain Routing entspricht. Wir entschieden uns für die Subnetzmaske 255.255.248.0. Ausgehend von unserem bisherigen Adressbereich 192.168.115.* vergrößert sich dieser auf 192.168.112.* – 192.168.119.*. Gemäß der CIDR Schreibweise drückt sich das so aus 192.168.115.0/21. Das obige Beispiel sieht damit wie folgt aus:

192.168.115.2 11000000 10101000 01110011 00000020
192.168.115.12 11000000 10101000 01110011 00001100
192.168.116.2 11111111 11111111 01110100 00000020
255.255.248.0 11111111 11111111 11111000 00000000

 

Somit können jetzt alle Rechner miteinander kommunizieren.

 

Im nächsten Teil werde ich auf das konkrete Vorgehen bzw. auf das Konzept zur Migration eingehen.

User Groups

In den letzten Wochen ist mir immer wieder aufgefallen, dass einige Leute durchaus Interesse am Informations- und Gedankenaustausch haben, ihnen aber nicht bewusst ist, dass es hierfür gute Möglichkeiten gibt. Deswegen will ich hiermit auf diverse User Groups aufmerksam machen, von denen man inzwischen in fast allen großen Städten welche findet. Um kurz darüber aufzuklären, was eine UG denn ist, zitiere ich die Definition von Wikipedia: “Eine Anwendergruppe im Sinne einer Interessenvertretung von Personen, die das gleiche Software Produkt nutzen” (http://de.wikipedia.org/wiki/User_Group).

Ich persönlich habe mich auf folgende 3 Gruppen beschränkt, wobei es generell sinnvoll ist, bei Interesse den entsprechenden Xing Gruppen beizutreten:

Zu guter Letzt will ich noch auf eine Online User Group hinweisen, an der ich selbst allerdings noch nie teilgenommen habe. Weitere Infos findet ihr hier.

Blog gestartet

Hallo,

das ist mein erster Eintrag in meinem neuen Blog, der sich vorwiegend um IT Topics drehen wird. In diesem Kontext werde ich mich primär in der Domäne zu Microsoft Technologien bewegen und aus meinem beruflichen Alltag bei der Firma heco GmbH berichten. Verstärktes Augenmerk gilt hier der Entwicklung mit dem .NET Framework.

Für Kommentare, Kritik oder Anregungen wäre ich dankbar.

%d Bloggern gefällt das: