4.4 Internet Adressen und IP-Routing

Transkript

1 Rechnernetze 2 ( Arbeitsblätter ) B. Müller Internet Adressen und IP-Routing Adressen, Namen, Wege Im allgemeinen Sprachgebrauch sind Namen menschenlesbare dauerhafte Identifikationen einer Person oder Sachen. Adressen geben den Ort einer Person oder Sache an. Der Name ändert sich i.a. nie. Die Adresse ändert sich dagegen mit jedem Ortswechsel des adressierten Objekts. Der Weg (engl. route)) gibt an, wie man zum einem identifizierten Objekt gelangen kann. Er ändert sich sowohl mit der eigenen Position (Adresse), als auch mit der des Objektes, zu dem er führt. Der Sprachgebrauch in der Kommunikationstechnik entspricht dem informalen Verständnis nur teilweise. Er ist feiner ausgebaut und weicht auch teilweise von der Umgangssprachlichen ab. Namen sind anwendungsorientierte Identifikationen. Sie ändern sich nicht wenn das mit ihnen angesprochene Objekt bewegt. Adressen sind Identifikationen einer Schnittstelle. Die Adresse eines Objekts ändert sich i.a. wenn das adressierte Objekt verlagert wird. Wege (engl. Route) führen zum Identifizierten. Sie ändern sich mit dem Start- und dem Zielpunkt. Namen und Adressen machen nur Sinn in einem bestimmten Namensraum bzw. Adressraum. Ein Objekt kann durchaus in unterschiedlichen Namens- und Adressräumen unterschiedliche Namen und Adressen haben. Namen in einem Namensraum dienen dazu Objekte eindeutig identifizieren zu können. Diese Identifikation findet auf Anwendungsebene statt. Der Namensraum kann weltweit aber auch auf ein einzelnes LAN beschränkt sein. In der Regel ist der Namensraum und damit die Namen hierarchisch aufgebaut. Namen werden benutzt um Eigenschaften von Objekten bekannt geben zu können. Das wichtigste Beispiel einer Eigenschaft eines Objekts ist dessen Adresse. Wichtige Namensräume sind: DNS, NetBIOS und X500, die jeweils ihre eigene Struktur von Namen haben. Adresse sind immer Identifikationen von Schnittstellen zu einem Netz. Ein Adressraum umfasst immer alle tatsächlichen und potentiellen Schnittstellen zu einem Netz. Netze gibt es in zwei prinzipiellen Grundvarianten Schicht-2-Netze (LANs) und Schicht-3 Netze. Eine weitere Art von Adressen sind die Dienstzugangspunkte oder Ports, mit denen die Schnittstelle zu einer Dienstimplementierung angesprochen wird. Dementsprechend gibt es drei Arten von Adressen: Physikalische Adressen: Identifikation einer Schnittstelle zu einem Schicht-2-Netz; logische (Netz-) Adresse: Identifikation einer Schnittstelle zu einem Schicht-3-Netz; Dienstzugangspunkt (Service Access Point, Port): Identifikation einer Schnittstelle zu einer Anwendung (einem Dienst ) innerhalb eines Rechners. LANs sind in Bezug auf die Wegfindung immer unstrukturiert: Brücken oder Repeater analysieren niemals die Adressen eintreffender Rahmen, um über die Art der Weiterleitung zu entscheiden. Der Adressraum der physikalischen Adressen ist dementsprechend flach. Jede Adresse kann sich darum im Prinzip an jeder Stelle befinden. Adressen sind unstrukturiert und enthalten keinerlei Information in Bezug auf die Topologie des Netzes zu dem sie gehören.

2 - 2 - ( Arbeitsblätter ) Rechnernetze 2 Schicht-3 Netze sind strukturiert. Router analysieren die Adressen eintreffender Pakete um über ihre Weiterleitung zu entscheiden. Der Adressraum der logischen Adressen ist dementsprechend strukturiert. Eine Adresse kann nicht beliebig innerhalb des Netzes verschoben werden, da sie Informationen über ihre Position im Netz enthält. Im einfachsten Fall sind die (Schicht-3-) Netze in zwei Hierachiestufen eingeteilt: Das Gesamtnetz besteht aus einer Kollektion von (Sub-) Netzen. Eine Adresse hat dann einen Netzanteil der angibt in welchem (Sub-) Netz sich diese Adresse befindet. Eine solche Adresse kann dann natürlich nur in diesem (Sub-) Netz verschoben werden. IPX-Adressen und IP-Adressen sind so zweistufig strukturiert. Dienstzugangspunkte { die SAPs, Ethertypes und Ports - sind eine weitere Variante der Adressen. Mit ihnen werden Schnittstellen zu Diensten adressiert. Ein Port beispielsweise ist eine Adresse zwischen der Schicht-4-Implementierung und einer Anwendung. Ein Ethertype ist die Adresse über die der Treiber einer Ethernetkarte (Schicht-2-Implementierung) Daten an die Protokollsoftware (Schicht-3-Implementierung) ausliefert. Namen und logische Adressen haben also den strukturierten Aufbau gemeinsam. Aus dem Aufbau der Namen kann man ihre Position in einer Organisationstruktur ablesen. Aus demaufbau der logischen Adressen kann man ihre Position innerhalb der Netztopologie herauslesen. Physikalische Adressen und Dienstzugangspunkte sind unstrukturiert, da der jeweilige Adressraum keinerlei Struktur aufweist. Adressen in allen drei Formen identifizieren jeweils eine Schnittstelle. Sie werden beim Transport von Daten unterwegs benutzt. Namen werden dagegen niemals unterwegs benutzt. Sie dienen dazu Information über Objekte zu verwalten und zu verteilen. IP-Adressen werden zentral von einer von der Internet-Society beauftragten Organisation an ISPs (Internet Service Provider) und von diesen dann an Netzmanager und weiter an die einzelnen Systembetreuer vergeben Traditionelles IP-Routing ohne Subnetzmaske Ein IP-Paket wird von einer Station - egal ob Rechner oder Router - stets entweder direkt oder indirekt zugestellt. Bei der direkten Zustellung wird das Paket auf Schicht-2 sofort zu seinem Ziel gebracht, bei der indirekten Zustellung liegt zwischen Sender und Empfänger noch mindestens eine auf IP-Ebene operierende Zwischenstation, und damit mindestens zwei Schicht-2 Datentransporte. Beim Versenden eines IP-Pakets müssen von der sendenden Station einige Entscheidungen getroffen werden: Ist das IP-Paket direkt oder nur indirekt zustellbar? Über welche Schnittstelle muss es gesendet werden? In welchen Rahmen mit eventuell welcher Hardware-Adresse des nächsten Hops und welchem Schicht-2 Protokoll muss es gesendet werden. Die notwendigen Aktionen können grob in zwei Teilbereiche aufgeteilt werden: Schicht-3 Aktionen mit denen festgestellt wird, über welche Schnittstelle das Paket zugestellt wird, ob die Zustellung direkt oder indirekt ist und falls indirekt über welchen nächsten Hop (gegeben durch eine IP-Adresse) sie zu erfolgen hat. Schicht-2 Aktionen mit denen das Rahmenformat und eine eventuelle Hardware-Adresse bestimmt wird, das Paket in einen Rahmen verpackt und dann mit dem richtigen Protokoll gesendet wird.

3 Rechnernetze 2 ( Arbeitsblätter ) B. Müller Der Sendeprozess auf Schicht-2 ergibt sich aus der Konfiguration der Schnittstelle über die zu senden ist. Die Hardware-Adresse wird - falls das notwendig ist, falls also die Schnittstelle zu einem LAN führt durch das ARP-Protokoll bestimmt. Den Schicht-3 Anteil des lokalen Sendeprozesses bezeichnet man als IP-Routing. Das IP-Routing beruht ganz wesentlich auf der Routingtabelle. In ihr sind die Informationen über Zieladressen und die Wege dorthin zu finden. Man unterscheidet traditionelles und das klassenloses IP-Routing. Beim tradionellen IP-Routing wird beachtet zu welcher Klasse (A, B oder - C) eine Adresse gehört, beim klassenlosen IP-Routing, mit dem wir uns später beschäftigen werden, spielt die Klasse keine Rolle mehr. Beim tradionelle IP-Routing wurde zunächst nur die Klassenzugehörigkeit der Adressen beachtet. Später wurde die Sache mit Subnetzmasken verfeinert und schließlich lässt man heute alle Klasseninformationen gänzlich ausser Acht. Der Algorithmus des traditionellen IP-Routings ohne Subnetzmaske beruht auf einer Routingtabelle in der Zieladressen eine Adresse des nächsten Hops und eine Schnittstelle zugeordnet ist: (Ziel-) IP-Adresse -> (Gateway-) IP-Adresse, Schnittstelle und enthält folgende Schritte: 1. Suche in der Routing-Tabelle nach einen Eintrag des Ziel-Rechners. Falls vorhanden sende entsprechend der Information des Tabelleneintrags; sonst: 2. Zerlege die Ziel-Adresse entsprechend ihrer Klassen-Bits in Netzadresse und Hostanteil. 3. Suche in der Routing-Tabelle nach einen Eintrag der so erhaltenen Netzadresse. Falls gefunden sende entsprechend der Information des Tabelleneintrags; sonst: 4. Suche in der Routingtabelle nach einem default Eintrag. Falls gefunden sende entsprechend der Information des Tabelleneintrags; sonst: 5. Das Paket ist nicht zustellbar. Der Algorithmus sucht also in der Routingtabelle zuerst nach einem Eintrag der zur gesamten Adresse passt, dann nach einem der zur Netzanteil passt und schliesslich nach einem default- Eintrag. Wenn ein passender Eintrag mit Schnittstelle und Gateway (= nächster Hop) gefunden wurde, dann wird das Paket über die Schnittstelle zum Gateway gesendet. Handelt es sich um eine LAN-Schnittstelle, dann muss mit Hilfe von ARP noch die Hardware-Adresse gefunden werden. Die Konfiguration der Schnittstelle legt das passende Schicht-2-Protokoll fest. Es ist klar, dass dies nur funktioniert, wenn jedes Gateway in der Routingtabelle direkt erreichbar ist! ARP, Proxy-ARP, RARP und DHCP ARP, das Address Resolution Protocol dient dazu, zu einer direkt erreichbaren IP-Adresse die zugehörige Hardware- (LAN-) Adresse zu finden. ARP operiert LAN-weit. Genauer gesagt operiert es in einer Broadcast-Domäne. Mit einem LAN-Broadcast wird einfach nach dem Besitzer der fraglichen IP-Adresse gefragt. Im günstigsten Fall antwortet ein Rechner mit seiner LAN-Adresse, im ungünstigen Fall ist der Rechner mit der IP-Adresse abgeschaltet oder existiert nicht. Besonders ungünstig ist es wenn mehrere Rechner antworten, dann wurde eine IP-Adresse mehrfach vergeben. Die festgestellte Adresse wird in einem Cache - dem ARP-Cache - für einige Minuten in der Form (Ziel-) IP-Adresse -> LAN-Adresse

4 - 4 - ( Arbeitsblätter ) Rechnernetze 2 gespeichert und dann wieder gelöscht. Mit dem Kommando arp -a kann man sich den Inhalt des ARP-Caches ausgeben lassen. ARP-Pakete haben den Ethertype 0x0806 und folgendes Format (in Klammern die Länge der Felder in Bytes): Feld Beschreibung Hard{type(2) Typ der HW{Adresse (1 = Ethernet) Prot{type(2) Typ der Protokolls (0806 = ARP) Hard{size(1) Länge der HW{Adresse Prot{size (1) Länge der Protokoll{Adresse Op (2) Operation: 1 = Frage, 2 = Antwort S-HW-Adr (6) Sender HW-Adresse (Ethernet Adresse) S-IP-Adr Sender Protokoll-Adresse (IP Adresse) T-HW-Adr Target HW-Adresse T-IP-Adr Target Protokoll-Adresse Proxy ARP ist ein Mechanismus, bei dem eine Station eine gefälschte ARP-Antwort gibt. Eine Station beantwortet dabei für eine andere eine ARP-Anfrage. Das macht beispielsweise dann Sinn, wenn eine Station S für andere nur über einen Router R erreichbar ist und der Router an ihrer Stelle antwortet. Statt in der Routingtabelle jeder der Stationen einen Eintrag S->R vorzunehmen, beantwortet der Router ARP{Anfragen nach S, erhällt damit alle für S bestimmten Pakete und sendet sie weiter an S. RARP ist das Reverse Address Resolution Protocol Es hat die zu ARP inverse Aufgabe die IP- Adresse zu einer gegebenen Hardware-Adresse zu liefern. RARP wird beispielsweise eingesetzt, wenn plattenlose Rechner booten und anschliessend zu ihrer - in der Hardware festkonfigurierten - LAN-Adresse die IP-Adresse feststellen müssen. DHCP ist das Dynamic Host Configuration Protocol. Es dient wie RARP dazu Stationen im Bootprozess über ihre IP-Adresse zu informieren. Im Gegensatz zu RARP wird bei DHCP die IP-Adresse den LAN-Adressen nicht fest zugeordnet, sondern dynamisch aus einem Pool verfügbarer Adressen vergeben. Damit kann mit der eventuell knappen Ressource IP-Adressen rationeller umgegangen werden, da nur den jeweils aktiven Stationen eine IP-Adresse zugeordnet werden muss. Diese dynamische Vergabe passt allerdings nicht zu zu der statischen Zuordnung von DNS-Namen zu IP-Adressen IP-Routing mit Subnetzmasken Subnetzmasken komplizieren den Prozess des IP-Routings: Jede Schnittstelle aller Stationen muss neben der IP-Adresse auch noch auf eine Netzmaske konfiguriert werden. Diese Masken werden dann beim Versenden oder Weiterleiten von IP-Paketen beachtet. Der entsprechende Algorithmus des tradionellen IP-Routings mit Subnetzmaske beruht auf einer Routingtabelle in der Zieladressen eine Adresse des nächsten Hops und eine Schnittstelle zugeordnet ist: (Ziel-) IP-Adresse -> (Gateway-) IP-Adresse, Schnittstelle und enthält folgende Schritte:

5 Rechnernetze 2 ( Arbeitsblätter ) B. Müller Suche in der Routing-Tabelle nach einen Eintrag des Ziel-Rechners. Falls vorhanden sende entsprechend der Information des Tabelleneintrags; sonst: 2. Zerlege die Ziel-Adresse entsprechend ihrer Klassen-Bits in Netzadresse und Hostanteil. Suche eine Schnittstelle, die auf die so gefundene Netzadresse konfiguriert ist. 3. Falls es sie gibt wende die eventuell vorhandene Netzmaske dieser Schnittstelle auf die Zieladresse an. Dies ergibt u.u. eine neue Netzadresse. 4. Suche nach einer Schnittstelle, deren IP-Adresse einen Netzanteil hat, der gleich der jetzt erhaltenen Netzadresse ist. Falls gefunden sende über diese Schnittstelle. sonst: 5. Suche in der Routingtabelle nach einem default Eintrag. Falls gefunden sende entsprechend der Information des Tabelleneintrags; sonst: 6. Das Paket ist nicht zustellbar Variabel lange Subnetzmasken Unter Umständen ist es sinnvoll mit unterschiedlich Subnetzmasken zu arbeiten. Sollen beispielsweise drei Standorte vernetzt werden, von denen der eine doppelt so groß ist wie die beiden anderen, dann wird man einen IP-Bereich sicher nicht gleichmäßig aufteilen wollen, sondern dem einen die eine Hälfte der Adressen zuordnen und den beiden anderen zusammen die andere Hälfte. Das Klasse-C Netz kann nach diesem Muster in drei Bereiche aufgeteilt werden, von denen der eine doppelt so groß ist wie die beiden anderen: Netzid (binär) Netz Netz Netz 3 Das ergibt folgende Netzadressen und Masken: Netzadresse Maske Netz Netz Netz Wenn die drei Subnetze in einem Router zusammengeführt werden, dann muss dieser unterschiedlich lange Masken an unterschiedlichen Schnittstellen verwenden. Dies nennt man variabel lange Subnetzmasken. Ein Netz mit variabel langen Subnetzmasken ist etwas unübersichtlicher als eins in dem überall die gleiche Maske verwendet wird. Bei älteren Geräten kann es auch vorkommen, dass die Software nicht mit den unterschiedlichen Masken korrekt umgehen kann.

6 - 6 - ( Arbeitsblätter ) Rechnernetze Klassenloses IP-Routing: CIDR Das traditionelle IP-Routing ist klassensenitiv (classfull): die Klassenbits geben den Bereich der Netzadresse an. Durch eine Subnetzmaske kann der Bereich erweitert aber nicht verkleinert werden. Beim klassenlosen IP{Routing (Classless Interdomain Routing, CIDR) werden die Klassenbits vollständig ignoriert. Jeder Adresse wird eine beliebig lange Maske zugeordnet, die angibt welcher Bereich das Netz und welcher die Station in diesem Netz identifiziert. CIDR hat verschiedene Vorteile, die dazu geführt haben, dass es heute allgemein eingesetzt wird. Mit klassenlosem Routing kann man zunächst und vor allem mehrere Klasse-B oder Klasse-C Netze zu einem Supernetz zusammenfassen. Die Adresse mit der Maske fasst beispielsweise 256 Klasse-C Netze bis zusammen. Sind alle diese Netze in einem Router über das gleiche Gateway erreichbar, dann kommt dieser mit einem statt 256 Einträgen in seiner Routingtabelle aus. Das ist heute besonders wichtig, da zum einen der IP-Adressraum weitgehend vergeben ist und die Routingtabellen in den zentralen Routern des Internet so groß sind, dass jede Möglichkeit zur Vereinfachung sehr nützlich ist. Zum anderen werden heute statt einer der kaum mehr verfügbaren Klasse-B Adressen oft Blocks von Klasse-C Adressen vergeben, die dann mit einer Supernet-Maske zusammengefasst werden können. Klassenloses IP-Routing vereinfacht letztlich auch den Prozess des IP-Routings selbst. Wenn alle Adressen mit einer Maske versehen sind, dann muss diese nicht erst über eine Schnittstelle herausgefunden werden, sie ist in der Routingtabelle vorhanden und mit der Zieladresse verknüpft. Es muss nur noch der Eintrag mit der größten Übereinstimmung gesucht werden. Der entsprechende Algorithmus des klassenlosen IP-Routings beruht auf eienr Routingtabelle, in der Zieladressen eine Maske, die Adresse Adresse des nächsten Hops und eine Schnittstelle zugeordnet ist: (Ziel-) IP-Adresse -> Maske, (Gateway-) IP-Adresse, Schnittstelle und enthält folgende Schritte: 1. Suche in der Routingtabelle nach dem Eintrag der am weitesten (von links nach rechts) mit der gegebenen Adresse übereinstimmt. Die Maske gibt dabei an, welche Bits des Tabelleneintrags relevant sind. Falls vorhanden sende entsprechend der Information des Tabelleneintrags; sonst: 2. Das Paket ist nicht zustellbar Als Beispiel nehmen wir einen Rechner der eine Schnittstelle zu einem Ethernet-Netz hat, dem das IP-Netz mit der Maske zugeordnet ist ist die Adresse des Default-Routers. Die Routingtabelle dieses Rechners der klassenloses IP-Routing unterstützt kann mit dem Kommando route ausgegeben werden: > /sbin/route -vn Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface UH dummy U eth U lo UG eth0

7 Rechnernetze 2 ( Arbeitsblätter ) B. Müller Die Tabelleneinträge bedeuten dabei zeilenweise: ist Eintrag für einen Rechner, alle Bits der Adresse zählen (Maske). Ein Gateway wird nicht benötigt kann über die Schnittstelle dummy0 direkt erreicht werden. (Es ist die Adresse des Rechners selbst.) ist eine Netzadresse. Dieser Eintrag ist für die ersten 24 Bits relevant. Jede Adresse deren erste 24 Bits mit übereinstimmen kann über die Schnittstelle eth0 (Ethernet-Schnittstelle) direkt erreicht werden. Der dritte Eintrag beschreibt die Loopback Netzadresse Die Adresse des letzten Eintrags schließlich hat keinerlei relevanten Bits. Der Eintrag passt damit zu jeder Adresse. Jede Adresse (für die kein besserer Eintrag in der Tabelle zu finden ist) kann über die Schnittstelle eth0 und das Gateway (den nächster Hop) erreicht werden. (Es ist der Eintrag für den Default-Router.) Wird in dieser Tabelle nach einem passenden Eintrag gesucht, dann werden alle mit der Maske als relevant eingestuften Bits verglichen. Der Eintrag mit der längsten Übereinstimmung (also der von den passenden mit der längsten Maske) zählt. Die Adresse passt beispielsweise zum ersten, zweiten und vierten Eintrag. Da der erste in 32 Bits, der zweite in 24 und der vierte in 0 Bits übereinstimmen wird der erste Eintrag ausgewählt.

8 - 8 - ( Arbeitsblätter ) Rechnernetze 2 5 SNMP: Netzmanagement 5.1 Das SNMP-Modell SNMP steht für Simple Network Management Protocol. Dieses Protokoll regelt die Kommunikation (mindestens) einer Managementstation mit ihren Agenten in den Netzkomponenten. Das Netzmanagement nach SNMP setzt also eine funktionierendes Netz voraus! Über dieses Netz hat eine beobachtende und administrierende Managementstation Zugriff auf eine Reihe von Netzkomponenten. Mit einem Management-Systems nach SNMP können also Netzkomponenten von einem zentralen Kontrollpunkt aus administriert werden. Netzkomponenten Eine Netzkomponente (managed node) kann im Prinzip alles sein, was über eine Netzverbindung erreicht werden kann: Rechner (Sever, Arbeitstation), Peripheriegeräte (Netzdrucker, etc.) Netzkomponenten im eigentlichen Sinn (Router, Brücken, Switche, Hubs, etc.) Eine Komponente ist SNMP-fähig oder wie man auch sagt managebar, wenn sie netzfähig ist und einen SNMP-Agenten enthält. Der Agent ist die SNMP-Implementierung in einer Netzkomponente und hat zwei Aufgaben: Die Kommunikation mit der Managementstation und die lokale Umsetzung deren administrativer Anweisungen. Wenn beispielsweise die Managementstation von einem SNMP-fähigen Hub den Status einer Schnittstelle erfragt, dann muss der Agent diese Information aus den internen Daten- oder Hardwarestrukturen des Hubs ermitteln und zurücksenden. Es ist klar, dass die Agenten aufs engste mit dem System verwoben sind, dem sie Management-Fähigkeit verleihen. Bei Netzkomponenten oder Peripheriegeräten wird der Agent ent-

9 Rechnernetze 2 ( Arbeitsblätter ) B. Müller weder als Bestandteil des Systems oder als optinaler Hardwareeinschub geliefert. Bei Rechnern ist der Agent betriebssystemspezifisch und wird typischerweise als Prozess aktiviert. Managementsystem und -Anwendung Von der Managementstation aus werden die Netzkomponenten überwacht und administriert. Die Komoponenten enthalten als SNMP-Implementierung Agenten, die eng mit dem jeweiligen System (Hardware / Betriebssystem) zusammenarbeiten. Die SNMP-Impementierung auf der Mangementstation wird Mangementsystem genannt. Ein Managementsystem umfasst typischerweise folgende Komponenten: eine Implementierung des SNMP-Protokolls, eine Basisanwendung für elementare Admistrationsaufgaben, erweiterbare, konfigurierbare Anwendungen und eine erweiterbare, konfigurierbare graphische Benutzerschnittstelle. Ein Managementsystem ist meist eine recht komplexe Anwendung mit einer graphischen Benutzeroberfläche. Jedes Netz ist individuell aus unterschiedlichen Komponenten aufgebaut. Ein Managementsystem bietet darum immer nur eine gewisse Grundfunktionalität, die durch eingene Anwendungen erweitert werden muss. Zur Grundfunktionalität gehört beispielsweise die Fähigkeit in regelmäßigen Abständen bestimmte Nachrichten nach dem SNMP-Protokoll an einen bestimmten Agenten zu versenden, bzw. Informationen von einem Agenten zu empfangen. Eine spezifische Anwendung könnte dann so aussehen, dass alle 2 Minuten der Router mit der Adresse X.Y.Z.U nach der Anzahl der Bytes befragt wird, die über seine Schnittstellen gegangen sind. Daraus könnten man dann eine Graphik erstellen, die den Verkehr veranschaulicht und weiter, wenn der Verkehr 30 Minuten lang auf 0 Bytes abgesunken ist, den Netzmanager per Handy alamieren. Die Anwendungen müssen mit einem gewissen Ziel realisiert werden. Mögliche Ziele einer Mangementanwendung sind beispielsweise: Konfiguration:die Konfiguration einer Netzkomponente wird verändert; Performance: die Leistungsdaten des Netzes werden überwacht, wo und wann treten Engpässe auf; Abrechnung (Accounting): Daten sammeln um Netzkosten ihren Verursachern zuweisen zu können; Fehler: frühzeitige Entdeckung und Lokalisierung von Fehlern (z.b. kein Datenverkehr mehr aus Subnetz XY). Die Kunst des Netzmanagements besteht darin solche Anwendungen mit Hilfe eines Managementsystems situationsgerecht zu realisieren. SNMP-Agenten sind Bestandteil der Geräte (Hardware und/oder Betriebssystem). Mangementsysteme sind Software-Anwendungen, die für verschiedenen Plattformen und auch plattformübergreifend angeboten werden. Bekannte Beispiele sind etwa: Sun: Solstice SunNet Manager HP: HP-OpenView Cabletron: Spectrum IBM: NetView freie Software: Tkined Solche Systeme können und müssen an die spezielle Netzsituation angepasst werden. Das geht nur mit einem gewissen Verständnis für die Probleme allgemein und im jeweiligen im Netz. Ein Managementsystem ist darum ohne Konfiguration und permanente Betreuung durch eine kompetente Person völlig wertlos.

10 ( Arbeitsblätter ) Rechnernetze 2 SNMP ist ein sehr wichtiger Standard. Alle relevanten Hersteller bieten heute Netzkomponenten an, die SNMP beherrschen. Alle neuen Netzkomponeten sollten mit SNMP-Unterstützung beschafft werden. SNMP-fähige Netzkomponenten und eine Managementstation mit der entsprechenden Software machen aber noch kein Netzmanagement. Dazu gehören noch die Anwendungen in Form speziell auf das jeweilige Netz zugeschnittener Beobachtungs- und Auswertungsroutinen und ein Netzmanager der mit den erzeugten Informationen umgehen kann. Insgesamt besteht ein SNMP-basiertes Management aus folgenden Komponenten: SNMP-fähige Netzkomponenten, eine Managementstation auf dem das Managementsystem läuft, auf das Netz zugeschnittene Management-Anwendungen (Erweiterungen des Managementsystems), mindestens ein Netzmanager, der die Anwendungen konzipiert und die von ihnen erzeugten Informationen sinnvoll interpretiert 5.2 Netzmanagement ohne SNMP SNMP ist ein System zum Management von Geräten. Vereinfacht gesagt automatisiert es einen Boten, der herumläuft, und die Lämpchen und Schalter der Netzkomponenten beobachtet bzw. bedient. Oder, etwas moderner, ersetzt es eine Person, die sich per Telnet auf den Komponenten einloggt und dann mit Hilfe einer kryptischen komponentenspezifischen Kommandosprache Daten des Geräts abfragt oder modifiziert. Ein Grundvoraussetzung für den Einsatz von SNMP ist die Existenz eines funktionierenden Netzes. Es kann also nur präventiv und zur Diagnose (bis wohin funktioniert es wie?) eingesetzt werden. Im Schadensfall müssen andere Mittel zum Einsatz kommen. Mit SNMP kann man natürlich auch bei einem funktionierenden Netz nicht alle Netzadminstration erledigen. Die Qualität eines Kabels beispielsweise kann ein SNMP-System nicht messen. Viele Aktivitäten in der Betreuung der Netze können von einem (SNMP-) Managementsystem prinzipiell nicht übernommen werden. Es muss darum immer durch andere Hilfsmittel ergänzt werden. Die wichtigsten sind: Kabeltester Protokollanaysator Einfache Erreichbarkeitstests Mit einem Kabeltester lässt sich die Qualität einer physikalischen Verbindung prüfen. Kein Kabel darf ungeprüft (ungemessen) in Betrieb gehen. Hinter einer Netzstörung stecken sehr oft physikalische Fehler, die nur mit einem Kabeltester identifiziert werden können. Ein Protokollanalysator - auch (Netz-) Monitor genannt - ist ein Hilfsmittel, mit dem Datenpakete von der Leitung abgegriffen und analysiert werden können. Das bekannte Programm tcpdump ist ein Beispiel für einen Protokollanalysator. Es schaltet zunächst die Netzschnittstelle in den sogenannten promiscuous mode. In diesem Modus liefert die Schnittstelle alle Rahmen - nicht nur die an die Station gerichteten - an die Software aus. tcpdump analysiert den Inhalt des Rahmens und stellt ihn dann auf dem Bildschirm textuell dar. Die Art der Analyse und Darstellung kann mit diversen Parametern beeinflusst werden. Man konsultiere die man- Seiten. Der Netzmanager sollte immer mit einen Protokollanalysator in Form eines tragbaren Geräts ausgestattet sein, um Probleme vor Ort lösen zu können: kommen hier überhaupt die erwarte-

11 Rechnernetze 2 ( Arbeitsblätter ) B. Müller ten Datenpakete an, welche Datenpaktete sendet das System aus? Wer erzeugt eigentlich die Last in diesem Segment? Das tragbare Gerät kann ein normaler Laptop mit Analyse-Software sein. Besser sind aber spezielle Geräte die mit besonders leistungsfähigen Netzschnittstellen ausgestattet sind und auch über eine umfangreiche Software zur statistischen Analyse einer großen Anzahl von Datenpakteten verfügen. Einfache Erreichbarkeitstests sind mit ping und traceroute möglich. Das ping-programm testet die Erreichbarkeit mit Hilfe von ICMP-Nachrichten. ICMP ist ein Kontroll- und Fehlermeldungsprotokoll auf der IP-Ebene. Eine Antwort (ein ICMP-Echo-Reseponse Paket) auf eine ping-anfrage (ein ICMP-Echo-Request Paket) ping rechner zeigt normalerweise an, dass die Kommunikation bis einschließlich der IP-Ebene funktioniert. Das Programm traceroute sendet mit einem Aufruf wie traceroute rechner IP-Pakete mit einer beschränkten Zahl erlaubter Routerdurchgänge (TTL-Feld im IP-Paket) in Richtung rechner. Ein Router den ein solches Paket passiert zählt die Zahl zurück und sendet eine ICMP-Fehlermeldung zurück wenn dabei 0 erreicht wird. Beginnt man mit maximal einem Routerdurchgang und steigert die Zahl der erlaubten Routerdurchgänge bis das Ziel tatsächlich erreicht wird, dann kann mit Hilfe der so provozierten Fehlermeldungen der Weg zum Ziel über die dazwischen liegenden Router festgestellt werden. Zur genauen Beschreibung des Programms konsultiere man die man-seiten. Neben den Dingen auf der Hardware- und Verbindungsebene, die mit SNMP prinziell nicht machbar sind, gibt es Administrationsaufgaben, die zwar vom Prinzip her mit SNMP zwar möglich wären, bei denen dessen Einsatz aber nicht üblich ist. Dinge wie Benutzerverwaltung oder die Konfiguration von Anwendungen sind noch nicht mit SNMP-Systemen machbar. Bis heute beschränkt sich der Einsatz von SNMP-Systemen im wesentlichen auf Netztechnik im engeren Sinn (Schicht 1 bis 4). Es ist aber ein offenes Konzept, eine Management-Plattform die jederzeit um neue Aktionsfelder erweitert werden kann und auch ständig in vielfältiger Art erweitert wird. Diese Offenheit ist ein ganz wichtiger Aspekt von SNMP. Das System muss im Prinzip jede Art von Netzkomponente ansprechen können: es muss sie nach ihrem Zustand befragen und diesen auch beeinflussen können. Das auch gilt für solche Systeme die es noch gar nicht gibt und über deren Eigenschaften wir noch nichts wissen. 5.3 Das SNMP-Protokoll SNMP hat zwei wesentliche Aspekte: Das SNMP-Protokoll, die MIBs Das SNMP-Protokoll definiert die Form der Kommunikation zwischen dem Managementsystem und den Agenten vor Ort in den Netzkomponenten. Die MIBs beschreiben die Fähigkeiten der Komponenten und legen damit den möglichen Inhalt der Kommunikation fest. Das SNMP-Protokoll setzt auf UDP auf. Ohne funktionierte Netzwerkschicht gibt es darum kein SNMP-basiertes Netzmangement. Das Protokoll definiert verschiedene Nachrichtentypen mit denen die Werte eines Objekts abgefragt bzw. verändert werden können. Unter einem Objekt stellt man sich am besten eine Art Variable vor, die in der Netzkomponete verwaltet wird und eine von deren Eigenschaften reflektiert.

12 ( Arbeitsblätter ) Rechnernetze 2 Zahl der Schnittstellen, IP-Adresse einer Schnittstelle, Eintrag in der Routingtabelle sind Beispiele für solche Objekte. Die Nachrichten des SNMP-Protokolls dienen der Abfrage und dem Setzen von Werten der Objekte. Zur Abfrage sind dies im einzelnen: get-request - Manager ->Agent - Mit dieser Nachricht fragt der Manager den Werte eines bestimmten Objektes ab. Der Manager gibt dazu einen eindeutigen Objekt-Bezeichner des Objekts an. Der Agent antwortet mit der aktuellen Objekt-Instanz (d.h. dem Wert) in einer getresponse-nachricht. get-next-request - Manager ->Agent - Das ist eine Abfrage, mit der der Wert des nächsten Objektes festgestellt wird. get-bulk-request - Manager ->Agent - Wie get-next-request, nur dass der Agent mit mehreren aufeinanderfolgenden Werten (Objektinstanzen) antwortet. (Nur in SNMPv2 der Version 2 des Protokolls definiert.) Der Manager fragt mit get-next-request Objekt-ID nach dem Objekt, das den auf Objekt-ID folgenden nächstgrößeren Bezeichner hat. Der Agent antwortet mit dem entsprechenden Objektbezeichner und dessen Wert. Wer das nächste ist, wird durch eine universelle Reihenfolge aller Objekt-Bezeichner festgelegt. Mit dieser Abfrage kann nach Objekten gefragt werden, ohne dass der Managementstation dazu alle Objektbezeichner genau bekannt sein müssen. Damit sind auch traversierende Abfragen möglich: Der Manager fragt einfach mit get-next-request nach dem was der Agent zuvor geantwortet hat. Komplexe Objekte (Tabellen) können in SNMP nur komponentenweise abgefragt bzw. manipuliert werden. Ist die Struktur eines komplexen Objektes unbekannt, dann kann sie nur mit traversierenden Abfragen gelesen werden. get-bulk-request stellt eine Optimierung der traversierenden Abfragen dar. Mit SNMP-Nachrichten können Netzkomponenten nicht nur befragt, sondern auch konfiguriert oder anderweitig manipuliert werden. Der entsprechende Nachrichtentyp ist: set-request - Manager -> Agent - Aufforderung den Wert eines Objektes zu ändern. Die Nachrichten in umgekehrter Richtung, Agent an Manager, sind: get-response - Agent <- Manager - Antwort auf Abfrage. trap

13 Rechnernetze 2 ( Arbeitsblätter ) B. Müller Agent <- Manager - Information über das Auftreten eines besonderen Ereignisses. (Nur in SNMPv2.) Ein Beispiel für eine einfache Abfrage und die entsprechende Antwort ist: snmpget public interfaces.iftable.ifentry.ifphysaddress.2 Hier fragt der Manager den Agent nach dem Wert eines Objekts. Der Manager ist hier ein einfaches Shell-Kommando der CMU-SNMP-Implementierung. Der Agent hat die IP-Adresse und der Objektbezeichner ist: interfaces.iftable.ifentry.ifphysaddress.2 Der gesuchte Wert ist die physikalische (Ethernet-) Adresse des angesprochenen Rechners. Dessen Antwort lautet: interfaces.iftable.ifentry.ifphysaddress.2 = OCTET STRING: Hex: C0 C8 E4 62 Man sieht, dass die Objektbezeichner hierarchisch aufgebaut sind und dass neben dem Wert auch der Objektbezeichner zurückgeliefert wird. Mit dem Kommando snmpwalk wird eine Traveresierung mit der Nachricht get-nextrequest angestoßen: ~ > snmpwalk public interfaces.iftable.ifentry.ifphysaddress interfaces.iftable.ifentry.ifphysaddress.1 = OCTET STRING: Hex: interfaces.iftable.ifentry.ifphysaddress.2 = OCTET STRING: Hex: C0 C8 E4 62 Um diese Werte festzustellen wurden 6 Nachrichten ausgetauscht: root: > tcpdump -i eth0 tcpdump: listening on eth0 11:02: schneewittchen.1024 > hamlet.snmp: GetNextRequest(9)[ snmp] 11:02: hamlet.snmp > schneewittchen.1024: GetResponse(7)[ snmp] 11:02: schneewittchen.1024 > hamlet.snmp: GetNextRequest(9)[ snmp] 11:02: hamlet.snmp > schneewittchen.1024: GetResponse(7)[ snmp] 11:02: schneewittchen.1024 > hamlet.snmp: GetNextRequest(9)[ snmp] 11:02: hamlet.snmp > schneewittchen.1024: GetResponse(7)[ snmp] Auf die dritte GetNextRequest-Anfrage liefert der Agent (hier hamlet) eine Antwort die public interfaces.iftable.ifentry.ifphysaddress nicht mehr als Prefix hat und snmpwalk bricht ab. 5.4 MIBs Neben dem festgelegten Kommunikationsprotokoll für die Verständigung von Client (Managementsoftware auf der Managementstation) und Server (dem Agent in der Netzkomponente)

14 ( Arbeitsblätter ) Rechnernetze 2 gibt es einen Mechanismus der es erlaubt eine beliebige Funktionalität einer Netzkomponente zu beschreiben und in das System einzubringen: die sogenannten MIBs. Eine MIB (Management Information Base) ist eine Beschreibung der (per SNMP abfragbaren und modifizierbaren) Funktionalität einer Komponente. Eine Brücke wird beispielsweise durch MIBs beschrieben, die unter anderem festlegen, dass sie Ports mit einer bestimmten Zahl und bestimmten Eigenschaften hat wie z.b. die Zahl der gesendeten und empfangenen Datenrahmen. Eine MIB beschreibt somit bestimmte funktionalen Fähigkeiten einer Netzkomponente. MIBs sind in Gruppen unterteilt, die jeweils Fähigkeiten einer Geräteklasse widerspiegeln. Jedes managebare Gerät muss entsprechend seiner Funktionalität bestimmte MIB-Gruppen unterstützen (sonst darf es nicht managebar oder SNMP-fähig genannt werden). Unterstützen bedeutet, dass das Gerät die in der MIB-Gruppe definierten Werte auf Anfrage entsprechend dem SNMP-Protokoll liefern bzw. modifizieren können muss. Beispielsweise gibt es im aktuellen SNMP-Standard MIB-II - der zweiten Version der MIB- Definitionen - die System-Gruppe, die von jeden Agent (managebaren Gerät) unterstützt werden muss. Sie definiert unter anderem Objekte die Name und Aufstellungsort des Geräts widerspiegeln. Eine andere Gruppe ist die IP-Gruppe, die von Agenten mit IP-Implementierung unterstützt werden muss. Ein Agent in einer SNMP-fähigen IP-Komponente (Rechner, Router) muss er beispielsweise die IP-Konfiguration all seiner Schnittstellen mitteilen können. Ein weiteres Beispiel ist die oben angesprochene Interfaces-Gruppe, die von jedem Gerät mit Schnittstellen unterstützt werden muss. In der MIB-Definition steht welche Objekte genau zu der jeweiligen Gruppe gehören. Dort findet man beispielsweise Festlegungen wie: iftable OBJECT-TYPE SYNTAX SEQUENCE OF IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A list of interface entries. The number of entries is given by the value of ifnumber." ::= { interfaces 2 } ifentry OBJECT-TYPE SYNTAX IfEntry ACCESS not-accessible56 KAPITEL 1. SKRIPT STATUS mandatory DESCRIPTION "An interface entry containing objects at the subnetwork layer and below for a particular interface." INDEX { ifindex } ::= { iftable 1 } IfEntry ::= SEQUENCE { ifindex INTEGER,

15 Rechnernetze 2 ( Arbeitsblätter ) B. Müller ifphysaddress PhysAddress, ifouterrors Counter, ifoutqlen Gauge, ifspecific OBJECT IDENTIFIER } ifphysaddress OBJECT-TYPE SYNTAX PhysAddress ACCESS read-only STATUS mandatory DESCRIPTION "The interface's address at the protocol layer immediately `below' the network layer in the protocol stack. For interfaces which do not have such an address (e.g., a serial line), this object should contain an octet string of zero length." ::= { ifentry 6 } Dies ist ein Ausschnitt einer MIB-Definition mit der die Basis für unsere Beispielabfragen nach den Schnittstellen oben gelegt wird (RFC-1213). Derartige MIB-Definitionen können von der Management-SW in textueller Form gelesen werden. Damit ist sie dann in der Lage entsprechende Anfragen nach dem SNMP-Protokoll (RFC-1157) abzusetzen. In der Netzkomponente müssen die MIB-Defintionen dagegen hart in der Systemsoftware oder gar der Hardware implementiert werden. Neben den offiziellen MIBs, die die Fähigkeiten aller Geräte einer Klasse festlegen und in RFC festgelegt sind, gibt es oft noch herstellerspezifische - private - MIBs. Eine SNMP-fähige Brücke eines Hersteller XY muss die offizielle System-, Interface- und die Bridge-MIB unterstützen. Daneben kann XY noch weitere Management-Funktionalität in seine Komponente einbauen und diese durch seine eigene private MIB, die XY-Bridge-MIB-Definition beschreiben. Wenn das Managementsystem diese private MIB-Definition liest, ist es sofort in der Lage die erweiterten Fähigkeiten der XY-Brücke zu nutzen. Da die offiziellen MIBs gewissermaßen den kleinsten gemeinsamen Nenner einer Geräteklasse darstellen, kommt den privaten MIBs eine recht große Bedeutung bei. 5.5 Identifikation von Objekten und Tabellenelementen Objekte werden nach einem System von Objektbezeichnern angesprochen. Objektbezeichner sind, wie wir oben in den Beispielen gesehen haben, hierarchisch aufgebaut. Dieser Aufbau macht eine universelle Eindeutigkeit möglich. Etwas verwirrend ist die Art sich auf den Wert eines Objekts zu beziehen: interfaces.ifnumber

16 ( Arbeitsblätter ) Rechnernetze 2 ist beispielsweise der Objektbezeichenr für die Zahl der Schnittstellen einer Komponete. Mit einer an den Objektbezeichner angehängten 0 fragt man nach dessen Wert. Z.B. mit snmpget interfaces.ifnumber.0 fragt man nach dem Wert der interfaces.ifnumber zugeordnet ist (nach der Zahl der Schnittstellen). Die Antwort ist dann beispielsweise: interfaces.ifnumber.0 = INTEGER: 2 Nur bei einfachen Objekten kann durch Anhängen einer Null an den Objektbezeichner Bezug auf den Wert genommen werden. In Tabellen funktioniert das nicht, da Tabellen nicht als Ganzes abgefragt werden können und darum viele Werte haben. In einer Tabelle kommen mehrere Werte mit dem gleichen Objektbezeichner vor. In der Interfaces-Gruppe gibt es beispielsweise eine Tabelle der Schnittstellen mit dem Objektbezeichner interfaces.iftable Die Tabelle besteht aus mehreren Zeilen, für jede Schnittstelle eine. Jede (!) Zeile der Tabelle hat den gleichen Objektbezeichner interfaces.iftable.ifentry Die physikalische Adresse einer Schnittstelle ist eine Spalte in dieser Tabelle und hat den Objektbezeichner: interfaces.iftable.ifentry.ifphysaddress Dieser Objektbezeichner bezieht sich auf die physikalische Adresse aller (!) Schnittstellen. Die physikalische Adresse einer bestimmten Schnittstelle erhält man, indem man an diesen Objektbezeichner einen Tabellen-Schlüssel (im Sinne der Datenbank-Theorie) anhängt. Ein Schlüssel einer Tabelle ist eine Folge von Werten der Indexfelder der Tabelle. Die Schnittstellentabelle hat ein einziges Indexfeld. Dies kann man an der MIB-Definition erkennen: ifentry OBJECT-TYPE SYNTAX IfEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An interface entry containing objects at the subnetwork layer and below for a particular interface." INDEX { ifindex } <<< Indexfeld ::= { iftable 1 } Der Index ist die Nummer der Schnittstelle. Mit einem Wert für die Spalte ifindex, der dem Objektbezeichener für die physikalische Adresse angehängt wird, kann dann eine bestimmte physikalische Adresse abgefragt werden. Z.B. die physikalische Adresse der zweiten Schnittstelle: interfaces.iftable.ifentry.ifphysaddress.2 = C0 C8 E4 62 bei einer Tabelle mit folgendem Inhalt: ifindex ifphysaddress (INDEX)

17 Rechnernetze 2 ( Arbeitsblätter ) B. Müller C0 C8 E4 62 Ein anderes Beispiel für eine Tabelle mit einer Indexspalte ist die Routingtabelle mit dem Ziel einer Route als Index: iproutetable OBJECT-TYPE SYNTAX SEQUENCE OF IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "This entity's IP Routing table." ::= { ip 21 } iprouteentry OBJECT-TYPE SYNTAX IpRouteEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A route to a particular destination." INDEX { iproutedest } << Index ::= { iproutetable 1 } Eine Abfrage nach dem Index des Tabelleneintrags mit dem Ziel sieht dann so aus: snmpget ip.iproutetable.iprouteentry.iprouteifindex Es gibt auch Tabellen die mehrere Indexspalten haben. Die Tabelle der aktiven TCP-Verbindungen gehört dazu: tcpconntable OBJECT-TYPE SYNTAX SEQUENCE OF TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "A table containing TCP connection-specific information." ::= { tcp 13 } tcpconnentry OBJECT-TYPE SYNTAX TcpConnEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "Information about a particular current TCP connection. An object of this type is transient, in that it ceases to exist when (or soon after) the connection makes the transition to the CLOSED state." INDEX { tcpconnlocaladdress, << Indexspalten tcpconnlocalport, <<---

18 ( Arbeitsblätter ) Rechnernetze 2 tcpconnremaddress, <<--- tcpconnremport } <<--- ::= { tcpconntable 1 } Die Tabelle der TCP-Verbindungen hat vier Felder als Index: Beide IP-Adressen und beide Ports einer Verbindung sind Index. Damit ist jede Spalte eine Indexspalte. Will man den Zustand einer bestimmten Verbindung abfragen, dann müssen vier Werte als Index angegeben werden: Snmpget tcp.tcpconntable.tcpconnentry.tcpconnstate Damit wird nach dem Zustand der Verbindung zwischen Port 23 (Telnet) auf Rechner und Port 1024 auf dem Rechner gefragt. Der datenbankartige Zugriff auf Tabellen ist notwendig, da die Größe einer Tabelle im Prinzip immer unbekannt ist.