work in progress
DDI Konzept
Dies soll ein generisches DDI-Konzept sein, das als Grundlage (Blaupause) dienen kann. Es soll exemplarisch die Stichpunkte liefern, die dann in einer konkreten Ausarbeitung auf die relevanten Absätze reduziert wird. Test wie gut man hier schreiben kann.
Einleitung
IPAM, DDI, Netzbasisdienste, Netznahe Dienste sind alles Begriffe für die Dienste, die man neben dem Kabel und der Hardware braucht, damit ein Netzwerk praktisch nutzbar wird.
Eine der wesentlichen Aufgaben von Computer-Netzwerken ist die Verwaltung von Netzwerkadresse (IPs), d.h. deren Zuordnung und Dokumentation. Das kann im einfachsten Fall ein Zettel oder Excel-Liste sein. In umfangreicheren Fällen nennt man das IP-Address Management (IPAM) und kann eine spezielle Softwarelösung sein. Nicht selten werden mit IPAM auch daran anschließende Dienste wie DNS und DHCP mit gemeint.
IPAM = IP-Address Management
Wenn man neben IPAM auch DNS und DHCP meint, wird auch zunehmend die Abkürzung DDI verwendet, um auszudrücken, dass man diese Netzbasisdienste als integralen Service auffasst.
DDI = DNS, DHCP, IPAM
Dabei will man alle Prozesse um IPs vereinfachen, automatisieren und zuverlässig machen. Wenn DNS-, DHCP- und IP-Adress-Management-Dienste als integrale Bestandteile eines Netzzugangs betrachtet werden, lassen sich einige sehr ähnliche Arbeitsabläufe zusammenfassen und deutlich einfacher gestalten und viele Mitarbeiter können gleichzeitig auf einer gemeinsamen Datenbasis arbeiten. Aus diesen Daten wird direkt die Konfiguration für die Dienste DNS und DHCP gespeist.
Der erste Vorteil entsteht, wenn alle Leute auf
einer Datenbasis arbeiten, die der realen Konfiguration entspricht.
Der zweite Vorteil – meinst unterschätzt – ist, dass Skripte und andere Werkzeuge die Datenbasis via API ansteuern können.
Netze und IPs können leicht mit weitere Eigenschaften (z.B. Umgebung, Verantwortlichkeit, Sicherheitszonen) versehen werden, die für die Automatisierung genutzt werden können (Security, ACLs, SDN usw.). Durch den Zugriff auf Netzbasisdienste via API wird die DDI-Software zum Dreh- und Angelpunkt für Cloud, XAAS, DevOps und Automatisierungen.
Die Beplanung und Dokumentation von IPs, der DNService und DHCP (evtl. NAC) erfordern sehr ähnliche Arbeitsschritte – IP raussuchen, Benennung und weitere Informationen (MAC, Netz, Loka-tion, Name). Diese Schritte sind im großen Maßstab mühsam und fehleranfällig (IP, MAC), so dass es oft sinnvoll ist diese Schritte in einem Service zu integrieren.
2.1 DDI als Überbegriff für netznahe Basisdienste
Der Begriff DDI – DNS DHCP IPAM – ist noch nicht weit verbreitet, denn bis vor wenigen Jahren sprach man einfach von IPAM bzw. IP-Adress-Management; meinte aber in der Regel DNS und DHCP mit. Denn auch wenn IPAM eine wichtige Aufgabe ist, hat es sich gezeigt, dass man für ein funktionierendes Netzwerk auch ein paar Basisdienste braucht, damit das ‚Netzwerk‘ funktioniert. Und da diese Dienste ähnliche Arbeitsschritte erfordern (IP und MAC raussuchen, dokumentieren, Namen vergeben), hat es sich etabliert, diese Dienste zusammenfassend als DDI zu bezeichnen.
DDI beschreibt also die – meist gebündelten – netznahen Basisdienste, die man über das ‚Kabel‘ hinaus braucht, damit ein Netzanschluss funktioniert; das sind in der Regel DNS, DHCP und IPAM und manchmal – je nach Auffassung – auch noch NTP, TFTP und PKI.
Leitlinien
Generelle Regeln für die Netzbasisdienste:
- Für die Konfiguration sind DNS-Namen zu nutzen (FQDN)
- Jede aktive IP hat einen FQDN, IPs ohne FQDN sind ‚verdächtig‘
- Jeder FQDN hat einen passenden Reverse-Record (PTR)
- Als Domain wird
demain ohne weiter Hierarchie bzw. Subdomain genutzt
- Alle relevanten Informationen sind im ersten Label des FQDN (Hostname) hinterlegt
- Als IP-Raum dient 1.2.3/16, 100.64/10 und abcd:1234::/32
- In speziellen Netzen wird DHCP zur initialen Betankung von Netzkomponenten genutzt
- Ping ist generell möglich (ICMP-Profil echo-reply)
Details und die einzelnen Services
IPAM
Die Dokumentation und Strukturierung von Netzwerkadressen ist die zentrale Aufgabe eines IP-Address Managements. Dabei muss garantiert werden, dass keine IP doppelt vergeben wird und der IP-Raum so aufgeteilt wird, dass er den Anforderungen des Routings und der Security genügt (und implizit einer Organisationsstruktur). Das bedeutet, dass Routen und/oder ACLs sich gut über Masken zusammenfassen lassen (route summarization, route aggregation). Diese Anforderungen lassen sich nicht gleichzeitig erreichen, insofern liegt je nach Anforderung die Gewichtung mehr bei 'schönen' Routen oder bei 'schönen' ACLs oder man versucht beiden ein bisschen gerecht zu werden.
Grundlage für die Aufteilung des IP-Raums – egal ob IPv4 oder IPv6 – ist eine Adresskonzept, in dem man die Struktur der IP-Aufteilung festlegt. Dabei versucht man die Anzahl der benötigen IPs, die für möglichst wenige Routen und wenige ACLs unter einen Hut zu bekommen. Gleichzeitig soll das Adresskonzept Reserven für zusätzliche Bedarfs und Anforderungen besitzen, so dass es für eine lange Zeit nutzbar ist, denn eine Anpassung des Adresskonzepts ist für die bestehende Infrastruktur mit sehr viel Aufwand verbunden (eine IP-Änderung bei komplexeren Systemen kommt quasi einer Neuinstallation gleich).
Ein IPv6-Adresskonzept ist insofern anders, als man nicht auf die Anzahl der benötigten IPs schauen muss (jedes Netz ein /64), und dafür seine Routen besser strukturieren kann – und auch muss, weil die Routen die Hardware stärker belasten (TCAM und Dual Stack, analoges gilt auch für ACLs).
Im Ergebnis soll ein überlappungsfrei routebarer IP-Raum zur Verfügung stehen, in dem die gegenläufigen Anforderungen abgewogen wurden.
DNS
DNS ist ein elementarer Dienst, ohne den größere Netze nicht funktionieren. DNS sorgt für eine eindeutige Auflösung von Namen zu IP-Adressen und umgekehrt.
Dadurch kann im Netzwerk mit sprechenden Namen gearbeitet und diese auch
zentrale leicht geändert und angepasst werden.
Dadurch schafft DNS eine Abtraktionsebene, die den Betrieb und die Administration einer IT-Infrastruktur vereinfachen.
- Man kann sprechende Namen statt IPs nutzen und kann, durch ein DNS-Namenskonzept unterstützt, die IPs benennen, gruppieren und ihnen Bedeutung geben.
- Durch DNS bekommt man auch für die Konfiguration eine Abstraktionsebene, d.h. man kann auf allen Systemen einen Namen für z.B. Log-Server, ftp-Server usw. konfigurieren; wenn sich dann die IP des Servers ändert, muss nur an einer Stelle – im DNS – die IP anpassen werden und nicht die Konfiguration auf jedem einzelnen Server, der diesen Server nutzt.
- Auch die Reverse-Auflösung – von IP zu Name statt von Name zu IP – ist sehr hilfreich, weil man in Logs und beim Debuggen mit ping und traceroute direkt die Namen sieht und ihnen Bedeutung zuordnen kann.
- Durch DNS kann ein Service – vom Benutzer unbemerkt – umgezogen (Georedundanz) oder auf mehrere Server verteilt werden (Lastverteilung).
Das im ersten Punkt angesprochene Namenskonzept ist, neben dem reinen Service und der Server-Hardware, der wesentliche Teil des DDI-Konzepts, weil darin den IPs Bedeutung, Struktur und Hierarchie gegeben werden.
Mit Blick auf IPv6 bekommt DNS noch mehr Bedeutung, da IPv6-Adressen kaum manuell handhabbar sind.
Nur auf einem überlappungsfrei routbaren IP-Raum kann man einen konsistenten DNS-Namensraum aufbauen.
Domänenkonzept oder Baumstruktur
DNS ist wie ein Baum strukturiert, um Eindeutigkeit und Auffindbarkeit der Namen zu gewährleisten. Vollständige Namen (FQDN) bestehen aus einem sog. Präfix oder Hostname (z. B. www), einem Domainnamen (z. B. spiegel.de) und einer Wurzel ('.', die meistens weggelassen wird).
Im Internet gibt es eine Wurzel (engl.: root), auf der alle Domainnamen aufbauen und von der ausgehend alle Domainnamen auflösbar sind. Wenn ein Intranet vom Internet entkoppelt ist, betreibt
Kunden eine eigene Wurzel (root-Server), von der alle internen Domains aufrufbar sind.
Vor diesem Hintergrund sind folgende Ziele für ein funktionierendes Domänenkonzept von Bedeutung bzw. sehr wichtig:
- Nur ein (DNS-)root. Dieser kennt alle Zonen des Intranet und kann sonstige Anfragen mit einem NXDOMAIN (existiert nicht) beantworten. Internet-Domains sind im Intranet nicht existent.
- Es gibt nur eine primäre DNS-Datenquelle. Diese primäre Datenquelle ist das DDI-Management. Dieses befüllt die DNS-Server, die von den Clients befragt werden. Ein Ausfall des DDI-Managements gefährdet somit nicht den Dienst an sich.
- Die DNS-Struktur ist übergreifend einsetzbar.
Kunden/Anwendungen können mit ihren Domains über die gleiche Infrastruktur angebunden werden.
- Es gibt an jedem
Rechenzentrumsstandort einen oder mehrere autoritative DNS-Server, d. h. vollwertige DNS-Server mit eigenen Konfigurationsdateien. Diese beantworten Anfragen von Clients rekursiv (d. h. der Client darf dumm/stub sein bzw. der Client fragt einfach seinen DNS-Server, welcher die Arbeit übernimmt, verschiedene DNS-Server abzufragen, die für die Auflösung notwendig sind).
-
Hinter einem SOA-Record werden in einem TXT-Record die verantwortlichen Ansprechpartner benannt.
- Darüber hinaus können Außenstellen reine Caching-DNS-Server haben, die ihre Anfragen an die autoritativen Slaves stellen, aber bereits gestellte Anfragen direkt beantworten können.
- Um nicht für alle Slaves Zugriffrechte pflegen zu müssen, werden die zentralen DNS-Server als zuständig für fremde Zonen (forwards) erklärt, sodass nur wenige ACL (Zugriffsrechte) für Netzübergänge gepflegt werden müssen.
- Auf den Slaves wird ISC BIND als Software eingesetzt.
- Das DDI-Management muss nicht hoch ausfallsicher sein, da es nur für Änderungen benötigt wird, aber den Betrieb ansonsten nicht gefährdet. Allerdings müssen vom DDI-Management regelmäßig Sicherheitskopien angelegt werden, weil es das zentrale System für Konfigurationen und Änderungen ist. Für die
XAAS muss diese Aussage relativiert werden, weil dieser Dienst in schneller Folge Änderungen für den Betrieb benötigt.
- Die Slaves müssen ausfallsicher sein, da sie den Betrieb gewährleisten. Die Ausfallsicherheit kann durch mehrere DNS-Server und/oder durch Failover-Setups (Heartbeat, Solaris-Cluster) erreicht werden.
- Anycast ist eine Möglichkeit, Ausfallsicherheit, Georedundanz, Loadbalancing und Sicherheit (vor DDoS - Distributed Denial of Service) auf einfachem Wege zu erreichen.
- Zusätzliche Optionen werden unterstützt: DNSSec, IPv6, zusätzliche Records (SRV, TXT, RP).
- Windows-Server dürfen keine eigenständigen DNS-Server sein, sondern nutzen den zentralen DNS-Dienst. Es gibt zwei Varianten, wie Active Directory (AD) sauber angebunden werden kann. In jedem Fall sind unabgestimmte DNS-Server auf ADs zu vermeiden.
- Es werden auch Anforderungen außerhalb des Standards für Microsoft-Domaincontroller oder Autodiscovery-Funktionen unterstützt, solange sie einem sauberen DNS-Setup nicht zuwiderlaufen.
_TCP
- Generell sollen Delegationen reduziert werden, weil
- Abfragen langsam werden
- nicht zu vermeiden ist, dass diese Server wieder weiterdelegieren und Anfragen noch langsamer werden
- ein Teil der DNS-Server, zu denen delegiert wird, nur unzureichend administriert werden
- Wenn eine Subdomain delegiert wird, ist es verpflichtend, dass die zentralen DNS-Server im Gegenzug Slaves für die delegierten Zonen sind (also einen Zonen-Transfer machen dürfen). Dies ermöglicht, einen Geschwindigkeitsvorteil und die Ausfallsicherheit der zentralen DNS-Server zu nutzen, sowie im Falle eines Fehlers erheblich leichter nach diesem suchen zu können. Technisch wird die Subdomain dann nicht mehr delegiert, sondern die zentralen DNS-Server sind mit den anderen DNS-Servern autoritativ für diese Subdomain.
- Auf Einträge in der Host-Datei (/etc/hosts), die nicht lokal sind, sollte verzichtet werden. Diese sollte nur den Kurznamen (Präfix) des Rechners enthalten. Der passende Domainname wird von der Resolver-Konfiguration bezogen (/etc/resolv.conf). Auch auf die Konfiguration des localhost-Eintrags kann verzichtet werden, da die DNS-Server diese Einträge kennen (localhost <> 127.0.0.1). Für Tests, ältere Networker-Installationen und ältere Oracle-Datenbank-Installationen können Host-Einträge nötig sein, diese sollten aber die Ausnahme bleiben.
Mit DNS ist das Domain Name System gemeint, das sind die verständlichen Namen – wie z.B. www.spiegel.de oder www.heise.de – die man im Browser oben eingibt. Ohne DNS müsste man immer und überall IP eingeben, die weit schlechter zu merken sind und leicht zu Verwechselungen führen. Aber auch über das Internetsurfen hinaus schafft DNS eine Abtraktionsebene, die den Be-trieb und die Administration einer IT-Infrastruktur vereinfachen.
• Man kann sprechende Namen statt IPs nutzen und kann, durch ein DNS-Namenskonzept unterstützt, die IPs benennen, gruppieren und ihnen Bedeutung geben.
• Durch DNS bekommt man auch für die Konfiguration eine Abstraktionsebene, d.h. man kann auf allen Systemen einen Namen für z.B. Log-Server, ftp-Server usw. konfigurieren; wenn sich dann die IP des Servers ändert, muss nur an einer Stelle – im DNS – die IP anpassen werden und nicht die Konfiguration auf jedem einzelnen Server, der diesen Server nutzt.
• Auch die Reverse-Auflösung – von IP zu Name statt von Name zu IP – ist sehr hilfreich, weil man in Logs und beim Debuggen mit ping und traceroute direkt die Namen sieht und ihnen Bedeutung zuordnen kann.
Das im ersten Punkt angesprochene Namenskonzept ist, neben dem reinen Service und der Server-Hardware, der wesentliche Teil des DDI-Konzepts, weil darin den IPs Bedeutung, Struktur und Hierarchie gegeben werden.
DNS-Namenskonzept
Das Namenskonzept ist die logische Struktur der Namen im DNS (FQDN z.B. parkausweis.konstanz.bw.de).
Wie die Namen genau aufgebaut werden ist meist umstritten, da in einem Namenskonzept oft sehr unterschiedliche Gruppen mit sehr unterschiedlichen Blickwinkeln und Anforderungen zusammenkommen und sich auf
ein Konzept einigen müssen.
Hier eine beispielhafte Liste von Anforderungen:
- Inventraisierung - favorisiert eine eindeutige Nummer (Inv.Nr.) im Hostname d.h. dem ersten Label
- Netzwerker favorisieren in der Regel einen am Routing orientierten FQDN
- Entwickler möchten gern ohne Restriktionen Namen vergeben
- Der IT-Betrieb vor Ort möchte evtl. sehr einfach kurze Namen haben
- Die operative Security möchte vielleicht Namen haben, die die Sicherheitszonen wiederspiegeln
- Der Datenschutz möchte verschleierte Namen ohne offensichtliche Zuordnung haben
- Der Support möchte genau das Gegenteil haben
- usw.
Damit soll gezeigt werden, dass ein DNS-Namenskonzept verschiedene Anforderungen erfüllen muss und in der Regel ein Kompromiss ist – und oft hitzig diskutiert wird.
Zum Glück ist DNS aber recht flexibel, so dass man bis zu einem gewissen Grad auch widersprüchliche Anforderungen erfüllen kann.
So kann z.B. über Aliase (CNAME) verschiedene Konzepte erfüllt werden (pc1234234-bla.company.com verweisst auf hugo.personal.mainau.konstanz.bw.de verweist auf 120.34.56.78).
DHCP
DHCP steht für Dynamic Host Configuration Protocol und bezeichnet die automatische Netzkonfiguration von einem – möglicherweise zentralen – DHCP-Server aus. DHCP ermöglicht dadurch ein zentrales IP-Konfigurations-Management und die Konfiguration weiterer zahlreicher Parameter (DHCP-Options). Nicht selten werden über die DHCP-Options noch nachgelagerte Services (TFTP, NFS, SMB), Skripte und Images geladen. Dabei ist DHCP aber der erste und wesentliche Baustein eines Zero Touch Provisioning oder Zero Touch Deployment, bei dem im Idealfall eine unkonfigu-riertes Gerät an das Netz angeschlossen wird und die komplette Konfiguration dieses Geräts statt-findet, ohne das ein Administrator das Gerät anfassen muss bzw. vor Ort sein muss. Man benötigt nur eine Hilfskraft, die den Strom anschließt und die Kabel steckt – sog. helping hands.
Genauso ist es durch DHCP möglich, skalierbar Konfigurationsparameter auszurollen oder anzupas-sen, z.B. andere DNS-Server, IP-Konfigurationen, Proxy-Konfiguration oder Ähnliches. Mit einem sog. static DHCP kann durch einen statischen Eintrag, einem Gerät bzw. Interface (MAC) immer die gleiche IP und spezifische Konfigurationen zugewiesen werden.
Die Netzwerkkonfiguration erfolgt grundsätzlich zentral durch DHCP. Der Mehrwert durch zentrale Konfiguration der wesentlichen Netzparameter und zusätzlicher Optionen (Zeit-Server, Proxy, Domainname, Log-Server usw.) wird genutzt. Für automatisierte Installationen können Netboot-Optionen (PXE) in DHCP genutzt werden. Sicherheitsbedenken kann durch DHCP-Filter auf Switch-Ebene begegnet werden. Wenn Network-Access-Control (NAC) gefordert wird, ist die IP fest an eine MAC-Adresse gebunden.
Es gibt mehrere DHCP-Server, die Ausfallsicherheit und Lastverteilung gewährleisten. Sie laufen in einem vollständigen Failover-Betrieb, d. h. sie kennen alle ausgegeben Leases, arbeiten auf den gleichen IP-Bereichen und sind nicht auf die Zusammenarbeit mit den Clients angewiesen (nicht unterschiedliche IP-Bereiche oder Anhängigkeit von Echo-Requests – die zwei üblichen Methoden, DHCP-Failover mit Einschränkungen einzurichten).
Grundlagen sind:
- Es gibt zwei zentrale DHCP-Server, die redundant im Cluster auf zwei unterschiedliche Rechenzentren verteilt DHCP-Anfragen beantworten. Technisch bedingt können bei dynamisch Pools (Zufällige Zuweisung aus einem Bereich) nur zwei DHCP-Server im Cluster betrieben werden. Bei statischer Zuweisung durch die MAC-Adresse können beliebig viele DHCP-Server zur Redundanz genutzt werden.
- Dem Standard (RFC 951, 1542, 2131, 2132, 2485) entsprechende Konfigurationen/Optionen werden unterstützt. Das sind z. B. IP, Subnetzmaske, Gateway, DNS-Server, domain-name, log-server, ntp-server, nis-server, netbios-server, proxy-conf und viele mehr.
- Dynamische DNS-Namen, die sich der Client selbst gibt, werden nicht unterstützt oder auf speziell vorgesehene Subdomains beschränkt. Namen dürfen nicht mit regulären Servern kollidieren, sonst könnte ein einfacher Client einen Serverdienst blockieren. (ggf. können dynamische DNS-Namen auf anderem Wege mittels NSUpdate, abgesichert durch kerberos, unterstützt werden)
- Netboot-Optionen z. B. für Sun/Jumpstart(x86/Sparc mit rarp) und PC/PXE (Novell, SCCM, Citrix Provisioning Server oder BSA ) können konfiguriert werden. Die eigentlichen Boot-Images müssen auf entsprechenden Servern via TFTP (SCCM Distribution Point oder Novell Proxy-DHCP) bereitgestellt werden.
Der Vollständigkeit halber sei hier noch Bootp, das Vorgängerprotokoll von DHCP, erwähnt. Bootp wird fast immer auch noch von dem DHCP-Service unterstützt. Es wird gelegentlich noch von Altgeräten und Druckern in ihren default-Einstellungen gesprochen. Wo es möglich ist, sollten die Geräte aber von Bootp auf DHCP umgestellt werden, da Bootp keine Leasetime kennt und daher ihre IP quasi ewig behalten können.
Zentrale IP Konfiguration, kein manuelles Turnschuhnetz, flexibel anpassbar, PXE-Betankung, Zero-Touch
Schnittstelle via Webinterface
Die meisten DDI-Software-Lösungen werden über ein Webinterface administriert. Die Optik und die Philosophie des User-Interfaces können sehr variieren und hängen vom jeweiligen Produkt ab.
Schnittstelle via API
Die DDI-Software sollte über eine API bedienbar sein. Oft wird dafür Rest oder Soup benutzt. Die Details und der Umfang der API-Unterstützung hängen vom jeweiligen Produkt ab und können variieren.
NTP
NTP ist wichtig für die Zeitsynchronisation von am Netzwerk angeschlossenen Komponenten und eine wichtige Voraussetzung für Authentifizierung, Logging, Zertifikate, Debugging und Synchronisation. Dieser Service erfordert spezielle Hardware und kann nicht direkt von einer DDI-Software erbracht werden, organisatorisch wird dieser Service aber zu den Netzbasisdiensten gezählt.
NTP ist ein grundlegender Dienst, der vom Netz-Betrieb erbracht werden sollte. Zu diesem Zweck werden mindestens drei dezidierter Zeitserver betrieben, die direkt an zwei Zeitnormale (meistens DCF77/PZF und GPS/GNSS) angeschlossen sind (Stratum 1). Diese synchronisieren sich auch gegenseitig (peer), sodass sie gegen Ausfall oder Manipulationen gesichert sind. Nachrangig können noch andere Zeitserver betrieben werden, die diese Stratum-1-Zeitserver abfragen (Stratum 2). Ein Zeitserver-Client (auch ein Server in der Rolle eines Clients) braucht mindestens drei Zeitserver zur Auswahl damit der Sync-Algorithmus korrekt arbeiten kann. Bei Bedarf wird das Zeitsignal noch mittels MD5-Hash signiert, um eine Manipulation des Zeitsignals auszuschließen.
Nachrangige Stratum-2-Server sind bei weitem ausreichend für die Anfragen von Clients ohne spezielle Ansprüche an die Präsision. Die Stratum-1-Zeitserver werden nur von Systemen genutzt werden, die sehr hohe Anforderungen an die Genauigkeit haben. Die Stratum-1-Server würden etwas an Genauigkeit verlieren, wenn sie von zu vielen Systemen genutzt werden (durch zu viele Interrupts der vielen Anfragen). Außerdem werden die Stratum-1-Server auch aus Sicherheitsgründen nicht direkt genutzt. Mit dieser Struktur wird effektiv die Genauigkeit für die Clients verbessert, da entsprechend ausgelegt Stratum-2-Server eine bessere Zeit liefern als überlastete Stratum-1-Server.
Gegebenenfalls muss bei Zeitservern in Rechenzentren darauf geachtet werden, dass vom Zeitserver Antennenkabel für DCF77 und GPS auf das Dach des Rechenzentrums benötigt werden und es je nach Technik und Kabelqualität die Länge der Antennenkabel limitiert ist. Speziell GPS-Antennen brauchen einen freien Blick auf den Himmel.
Zur Zeitsynchronisation aller im Netzwerk angeschlossenen Geräte werden in der Regel mehrere NTP-Server verwendet, die mit einer externen Zeitquelle (andere NTP-Server, DCF77 oder GPS) eine interne Uhr genau halten und mit Hilfe des NTP-Protokolls (UDP 123) Zeitstempel im Netz verteilen und die Laufzeiten herausrechnen.
Neben den naheliegenden Gründen einer Zeitsynchronisation – Logging, Debugging – ist es wichtig zu beachten, dass verschiedene Dienste eine gute Zeitsynchronisation voraussetzen.
Das gilt für:
• kerberos-Authentifizierung (AD)
• Zeitbasierte Zweifaktorauthentifizierung
• Backup und Repositories
• Datenbank-Transaktionen
• Debugging und Forensik (Kausalität bei 10GE)
• Zertifikate und PKI (IPSec)
• Virtualisierungen (z.B. VMWare) können das Problem erheblich verschärfen (Live-Migration)
Sehr wichtiger, aber meist unterschätzter Dienst
TFTP
Mitunter wird auch TFTP zu den Netzbasisdiensten gezählt, da die initiale Installation via PXE neben DHCP auch einen TFTP-Server mit einem bootloader erfordert. Dieser Service soll hier nur kurz erwähnt werden, um eine Idee zu geben, wie der Begriff Netzbasisdienste mehr oder weniger weit gefasst werden kann.
PKI
Mitunter wird auch eine PKI zu den Netzbasisdiensten gezählt, da die Arbeitsschritte in DNS und IPAM (IPv6) Zertifikate für TSL/SSL, DNSSEC, IPSec, 802.1x involvieren. Dieser Service soll hier nur kurz erwähnt werden, um eine Idee zu geben, wie der Begriff Netzbasisdienste mehr oder weniger weit gefasst werden kann.
NAC
Mitunter wird auch eine NAC (Network Access Control z.B. 802.1x) zu den Netzbasisdiensten gezählt, da eine statische DHCP-Reservierung fast die gleichen Schritte wie NAC erfordert und leicht in eine DDI-Lösung integriert werden kann. Dieser Service soll hier nur kurz erwähnt werden, um eine Idee zu geben, wie der Begriff Netzbasisdienste mehr oder weniger weit gefasst werden kann.
Auswahl einer DDI-Software
Mögliche Kriterien für die Auswahl einer DDI-Software sein.
Die DDI-Software muss die konsistente und effektive Bewirtschaftung eines IP-Bereiches ermöglichen und helfen die angrenzenden Services DNS und DHCP zu betreiben.
Folgende Anforderungen können wichtig sein:
- Erzeugen, Ändern, Löschen und Dokumentieren von Subnetzen und einzelnen IP-Adressen
- Teilen oder Zusammenfügen von Subnetzen
- Der rollenbasierte, geschützte Zugriff mehrerer beteiligter Gruppen muss möglich sein
- Verwaltung von VLANs
- VRF (VRF-Namen, route-distinguisher (RD), route-target (RT), doppelte Verwendung von IP-Ranges VRF-spezifisch)
- IPv6 sollte möglich sein
- Netzwerkscan oder Auslesen von ARP-Cache zur Detektion undokumentierter IPs
- Einmaliger Datenex- und import
- Kontinuierlicher Datenaustausch in eine CMDB/BWK (Configuration Management Database, betriebliche Werkzeugkette)
- API-Schnittstelle (Rest, Soap o.Ä.)
- Unterstützung von DHCP-Optionen, evtl. auch Vendor Class and Vendor-Specific
- Die Services laufen auf separaten Machinen, so dass ein Ausfall der DDI-Software nicht den eigentlichen Services berührt
- Authentifizierung gegen externe Quelle (LDAPS, AD, Radius, tacacs+)
- Unterstützung für NXUpdate mit kerberos keys
- Integration eines ActiveDirectory (mehr oder weniger invasiv mittels Agent, Konto oder NSUpdate)
Liste DDI-Software
Hier eine offene Liste möglicher DDI-Lösungen ohne Priorisierung irgendwelcher Art.
commercial
open source (free)
