Bevor wir uns intensiver mit SNMP beschäftigen, sollten wir etwas genauer auf die Grundlagen eines Netzwerkes eingehen.
2.1 Was ist ein Netzwerk ?
Ein Netzwerk ist ein bestimmter Weg, oder eine Anzahl bestimmter Wege, um Informationen, zwischen zwei oder mehr unabhängigen Einheiten zu befördern. Oder einfacher ausgedrückt, es ist eine Anzahl von Verbindungen, die zwei oder mehreren Computern bzw. Personen die Möglichkeit gibt, Informationen untereinander auszutauschen.
Menschen und Computer, die Informationen über ein Netzwerk miteinander austauschen wollen, benötigen ein common tranmission medium (gemeinsames Übertragungsmedium) um die Informationen zu übertragen, channel of communication (Kommunikationskanäle), und information transport mechanism (Informationstransport-Mechanismen). Für Menschen könnte man das common medium Luft nennen, der channel wäre der wahrnehmbare Teil der menschlichen Stimme, und die Kennzeichen einer bestimmten Sprache wie z.B. Standard Englisch zum entcoden und transportieren der Informationen. Für Computer ist das medium z.B. Kupferkabel oder Lichtwellenleiter, der channel eine bestimmter Volt-Pegel oder Frequenzen, und Netzwerk Protokolle wären die transport mechanism (Transport-Mechanismen).
Das einfachste Netzwerk, benötigt Mensch wie Computer zum kommunizieren. Jeder von Ihnen hat es sicher schon einmal benutzt. Es handelt sich um den Datenaustausch zwischen zwei Computern mit einer Diskette ( oft als Turnschuh-Netz bezeichnet). Hier ist die Diskette das transmission medium, das Laufwerk der communications channel, und der Mensch der information transport mechanism.
Viele Leute bringen den Begriff "Netzwerk" mit langen Distanzen in Verbindung (Tele - von Telekommunikation). Dies ist nicht immer so. Netzwerke können Geräte, die Lichtstunden (Voyager und Galileo lassen grüßen) wie wenige Meter voneinander entfernt stehen, verbinden.
Netzwerke kann man auch nicht allgemein als Komplex bezeichnen. Das Internet, welches Millionen von Computern und Menschen miteinander verbindet, ist genauso ein Netzwerk, wie meine zwei Computer zuhause.
Es gibt viele gemeinsame Begriffe für Netzwerke, unbeachtet ihrer Größe und Komplexität. Ein Netzwerk könnte z.B aus hungerten oder Tausenden von adressierbaren Geräten bestehen, die node, element oder host genannt werden. Netzwerk-nodes beinhalten Routers, Briges, Hubs, Workstations, Drucker, Modems und File-Server. Die Geräte eines Netzwerkes können in zwei Gruppen unterteilt werden : In solche die Informationen erzeugen und verarbeiten und in jene die den Datenfluss im Netzwerk regeln.
Ist der spezielle Zweck den Datenfluss zu regeln, nennen wir dieses Komponente z.B. : Hub, Bridge und Router. Diese Geräte regeln den Datenverkehr innerhalb eines oder mehrerer Netzwerke. Sie legen den Grundstein aller Netzwerke. Geräte, die das Netzwerk nicht direkt steuern, jedoch Daten erschaffen und verarbeiten, werden zur Gruppe der end-systems oder end-hosts (da sie alle an den Anfängen bzw. Enden des Netzwerkes liegen) gerechnet. Routers und Hosts können auch als Proxies eingesetzt werden, die fremde oder nicht netzwerktaugliche Geräte in ein Netzwerk einbinden, bzw. den Zugang ermöglichen. Bevor wir uns dem nächsten Kapitel widmen, werde ich etwas auf diese Geräte eingehen.
Hubs (Repeater)
Ein Hub (Schicht 1, OSI-Modell) wird dazu benutzt, eine Gruppe von Hosts zu einem Local Area Network (LAN) an einem einzigen Punkt zusammenzufassen. Multiple end-hosts, wie z.B. Drucker und Workstations, können alle an einen single-hub angeschlossen werden, der sie wiederum mit dem Netzwerk verbindet. Der Hub leitet den ganzen Datenverkehr zu den end-hosts und deren Datenverkehr an das Netzwerk zurück. Ein Hub kann wie ein Sternverteiler angesehen werden.
Ein Hub wird öfters als Repeater (Verstärker) bezeichnet, was ich persönlich etwas verwirrend finde. Unter einem Verstärker stelle ich mir ein Gerät mit einem Eingang und einem Ausgang vor. Kein Sternverteiler.
Basic hubs unterstützen keine error-check bzw. Routing Funktionen. Sie empfangen leglich Pakete, kopieren sie, und senden sie an die angeschlossenen Geräte weiter
Switching hubs (Schicht 2, OSI-Modell) besitzen dagegen einer gewisse Router-Intelligenz. Sie speichern das Paket zuerst in ihren RAM, überprüfen die Adressen und senden das Paket an den richten Empfänger. Pakete, deren Empfangsorte sich nicht im lokalen Netzwerk befindet, werden wieder an das Netzwerk zurückgegeben (um dort mit Hilfe einer Bridge an das andere Netzwerk weitergeleitet zu werden). Des weiteren werden nur unbeschädigte Paket weitergeleitet, beschädigte Pakete werden gelöscht.
Bridges
Bridges (Schicht 2, OSI-Modell) haben ähnliche Funktion wie ein Router. Eine Bridge leitet Pakete von einem Netzwerk zum Anderen. Sie liest ebenfalls die destination und die source Address eines Paketes. Wenn das Paket von einem Gerät aus dem Netzwerk A zu einem Gerät im Netzwerk B gesendet werden soll, erkennt dies die Bridge anhand der Adressen und entfernt das Paket aus dem Netzwerk A und bringt es in das Netzwerk B ein. Bridges arbeiten in der 2. Schicht des OSI Modells.
Routers
Routers (Schicht 3, OSI-Modell) sind Geräte, deren Hauptaufgabe darin besteht,
den Datenfluss eines Netzwerkes zu regeln. Jedes Datenpakete beinhaltet die Adresse des
Gerätes, welches das Paket abgesendet hat (source adress), und die Adresse des
Gerätes, welches das Paket erreichen soll (destiantion adress). Der Router liest
diese Informationen und entscheidet wohin das Paket gesendet werden soll. Falls der
Bestimmungsort des Zieles sich im selben Netzwerk wie der Router befindet, wird das Paket
direkt dorthin gesendet. Wenn der Bestimmungsort sich aber außerhalb des Bereiches des
Router befindet, wird das Paket an einen weiteren Router gesendet, bis es das
richtige Netzwerk erreicht hat.
Der Router besitzt Informationen über alle Geräte, die sich in seinem Bereich befinden.
End-hosts
Als end-host werden alle adressierbaren Geräte im Netzwerk bezeichnet, die Daten produzieren oder verwerten. Host sind netzwerktaugliche Geräte wie Server, Drucker und Workstations. Allein das Vorhandensein von Hosts und deren Bedürfnis nach Datenaustausch, gibt der Existenz eines Netzwerkes erste Priorität. Hosts werden auch end-systems genannt, da sie sich immer am Anfang oder am Ende eines Systems befinden.
Proxies
Proxy ist die Bezeichnung für ein Gerät, das für ein anderes Gerät als Moderator oder Übersetzer auftritt. Er gestattet Netzwerk-Komponenten verschiedene Übertragungsmedien und Protokolle zu verwenden. Routers und Bridges sind beiderseits dazu fähig als Proxies zu agieren. Die mögliche Funktion eines Proxy wäre z.B. als ein active management server oder eines passive translation gateway
Ein active management server ist verantwortlich für das Aktive wählen von Geräten, das sammeln von Management-Informationen, und das bereitstellen dieser Informationen für Management-Systeme. Wenn z.B. ein Modem über die serielle Schnittstelle an einer Workstation angebracht ist, weiß es nichts über Netzwerk Management oder wie es sich in einem Netzwerk mitteilen soll. Wenn nun irgendwo im Netzwerk ein network management system (NMS) etwas über das Modem wissen möchte, muss die Workstation zugunsten des Modems wie ein active management server agieren, die gewünschten Informationen des NMS einsammeln, sie in ein geeignetes Format umwandeln und dann zum NMS senden.
Ein passive proxy gateway übersetzt dagegen nur Management-Anfragen von einem Managementprotokoll zum Anderen. Der Proxy arbeitet wie ein Vermittler zwischen einem NMS und einem Gerät, welches ein nicht kompatibles Protokoll verwendet. Ein Anwendungsbeispiel wäre, den gateway als Übersetzer für das SNMPv2 nach SNMPv1 und zurück einzusetzen, wenn ein Gerät nur SNMPv1 versteht, das NMS aber mit SNMPv2 arbeitet.
Gateway
Schwierig ist die Kommunikation zwischen Systemen, die über vollkommen verschiedene Protokollstacks verfügen. Hier helfen Gateways. Das sind Geräte, die alle 7 Schichten des OSI Modells vollständig abbilden. Ein Beispiel für den Einsatz eines Gateways ist ein Rechner, der mit einem Fuß in einem Ethernet und mit dem anderen in einem S0-Bus (ISDN) steht.
2.2 TCP
Das Transmission Control Protocol bietet sichere Vollduplex-Verbindungen zwischen zwei Hosts. Bevor TCP Daten übertragen kann, muss es eine Verbindung zwischen zwei Hosts herstellen. Dieser Vorgang ist vergleichbar, mit dem Aufbau einer Verbindung zwischen zwei Telefonen. Nach Aufbau der Verbindung besteht ein sogenannter virtueller Schaltkreis oder eine virtuelle Verbindung, die über Port-Adressen identifiziert wird. Einige Port-Adressen sind für bestimmte Dienstprogramme reserviert, andere Ports werden dynamisch während des Verbindungsaufbaus zugeordnet. Daten lassen sich über diese virtuellen Verbindungen simultan in beide Richtungen übertragen. Nach Abschluss der Datenverbindung kann die TCP-Verbindung wieder geschlossen werden.
TCP beinhaltet Mechanismen für eine gesicherte Datenübertragung. Das heißt, TCP überprüft, ob ein Datenpaket tatsächlich beim Empfänger eingetroffen ist. Geht unterwegs ein Paket verloren, so wird es erneut gesendet.
Ich möchte nicht weiter auf dieses Thema eingehen, da dies sicher den Rahmen meiner Dokumentation sprengt
Man kann viele Modelle benutzen, um die physikalischen und schwer verständlichen Komponenten eines Computer-Netzwerk grafisch darzustellen. Es werden auch viele Modelle benötigt, da mit keinem vollständig die verschiedenen Systeme dargestellt werden können. Ein allgemein bekanntes Modell, zur Beschreibung von data communications protocols, ist das Open System Interconnect (OSI) Reference Model.
Die International Standards Organization (ISO) begann mit der Entwicklung des OSI Modells im Jahre 1977, und nahm es 1983, als gemeinsame Empfehlung für Diskussionen und Entwicklung, und als gemeinsame Beschreibung der Arbeitsweise zwischen Systemen, auf. Das OSI-Referenzmodell unterteilte die Funktionen der Daten-Kommunikation in sieben layer (Schichten) auf..
Die Grafik des OSI-Referenzmodell (Grafik1) zeigt uns den Namen und die Nummer einer jeden Schicht. Die Schichten sind vertikal wie ein Stapel organisiert. Jede Schicht empfängt die Daten von oben oder unten, verarbeitet sie, und gibt sie an die nächste Schicht weiter. Dies wird durch das Verwenden der in jeder Schicht bereitliegenden Protokolle erreicht.
System Processes and Sofware Applications |
|
: : |
|
7 | Application Layer |
6 | Presentation Layer |
5 | Session Layer |
4 | Transport Layer |
3 | Network Layer |
2 | Data Link Layer |
1 | Physical Layer |
: : |
|
Network |
Das OSI-Referenzmodell (Grafik 1)
Wenn eine Anwendung (application) Daten über das Netzwerk sendet, passieren die Daten alle layer (Schichten), beginnend mit der application layer und austretend an der physical layer. Wenn der host Daten empfängt, erreichen die Daten zuerst die physikal layer und treten an der application layer aus. Hier werden sie von den auf dem System ausgeführten Anwendungen entgegengenommen..
Die OSI Layers
Im OSI-Referenzmodell wohnt SNMP hoch oben in der application layer. Deswegen müssen die SNMP-Nachrichten alle Schichten unter der application layer passieren, bevor es auf das Kabel (oder Glasfaser, Luft, Kupfer...) trifft. Wir sollten zum besseren Verständnis noch einen kurzen Blick auf die verschiedenen Protokolle werfen, die in jeder Schicht des OSI Modells bereit liegen.
Physical Layers (Schicht 1)
Die physical layer erklärt die elektrischen, mechanischen, funktionellen und verfahrenstechnischen Eigenschaften, die benutzt werden um eine Reihe von Bits über ein physikalisches Medium zu senden. Diese Schicht beinhaltet die Medien (Koax, Glasfaser, Kupferkabel, Funkwellen usw.), die Schnittstellen (DB-25, C50, V.35, usw.) und die modulation and framing techniques (HDSL, ADSI, IEEE 802.3, FDDI, usw.). Ob Sie serielle Schnittstellen, 10BASE-T bzw. anders kompatible Netzwerkkarten ansprechen, sie werden immer an die physical layer verwiesen.
Data link layer (Schicht 2)
Die data link layer ist verantwortlich für die zuverlässige Lieferung von Daten auf der untersten Ebene. Ihre Dienste beinhalten das finden und beseitigen von Fehler in Datenpakete (error detection und correction), das framing von Daten (z.B. LLC, HDLC, SDLC, IEEE 802.2), und die Synchronsiation mit hardware handshake (Media Acces Control, oder MAC). Diese Schicht oder layer ist ebenso die Heimat von Ethernet, einer LAN-Technologie, die dazu benutzt wird, Daten zwischen Rechnern auszutauschen. Viele Netzwerke nutzen Ethernet, daher ist es die meist genutzte LAN-Technologie heutzutage.
Network layer (Schicht 3)
Die network layer richtet (und hält sie aufrecht) Verbindungen im Netzwerk ein. Außerdem adressiert und liefert sie Datenpaket an Hosts. Diese Schicht isoliert außerdem die oberen Schichten von den speziellen Details eines Netzwerkes. IP, PPP, IPX, und x.25 sind in dieser Schicht zu finden.
Transport layer (Schicht 4)
Die transport layer bietet folgende Dienste:
error detection (Fehlererkennung), correction (Korrektur), und software
flow control (softwarebasierende Datenflusskontrolle).
Viele dieser Dienste werden von sogenannten "verbindungsorientierten Protokollen",
die zuverlässige End-to-End Datenwiederherstellung und Datenflusskontrolle benötigen,
benutzt. Verbindungslose Transport
Protokolle (wie z.B. UDP)
garantieren nicht die Lieferung von Daten, und müssen daher ihre Zuverlässigkeit durch
die applicatin layer gewinnen. TCP und UDP sind in dieser Schicht zu finden.
SNMP benutzt das verbindungslose UDP Transportprotokoll. Da UDP selbst nicht zuverlässig ist, muss SNMP durch seine eigenen Sicherheitsfunktionen, Zuverlässigkeit beweisen.
Session layer (Schicht 5)
Die session layer ist verantwortlich für das Einrichten und Managen von Sessions (connections) zwischen Anwendungen und dem Netzwerk. Diese Schicht hat eine Funktion, die im Datenstrom synchronization points einbringt, die wiederum der application layer erlauben, Übertragungsfehler rückgängig zu machen. RPC, SAP, und NetBios sind in dieser Schicht zu finden.
Presentation layer (Schicht 6)
Die presentation layer ist zuständig für die Transformation der Daten aus der application layer in die Standardformate. Neben der Interpretation und Umsetzung der Daten bietet die presentation layer Dienste wie Verschlüsselung und Datenkompression.
Application layer (Schicht 7)
Die application layer wird von Anwendungen benutzt, welche Daten für die anderen 6 Schichten vorzubereiten. Daher ist sie die einzige Möglichkeit für Anwendungen, auf das Netzwerk zuzugreifen. FTP, Telnet, SMTP, und das X-Window-Systemprotokoll sind in dieser Schicht zu finden. Aber nicht alle Anwendungen die Zugriff auf das Netzwerk haben, sind automatisch in der application layer. Nur solche, die wiederum anderen Prozessen und Anwendungen den Zugriff ermöglichen, werden in der application layer aufgenommen.
Das Prinzip eines Application Program Interface (API) ist von der application layer hergeleitet. Eine Windows Anwendung, z.B., greift nicht direkt auf das W32 operating system zu, sondern benutzt die windows application layer (Win32 API). Die Microsoft SNMP APIs erlauben den Anwendungen, über das SNMP management protocol, das Netzwerk zu benutzen.
2.4 SNMP und das OSI Reference Model
SNMP selbst ist unabhängig davon, wie man in einem Netzwerk adressiert, überträgt, usw. . Daher wird man SNMP, obgleich ursprünglich für das TCP/IP-Protokoll in Ethernet Netzwerken gedacht, in vielen verschieden Netzwerken (Novell IPX/SPX, AppleTalk DDP, ARCNET, ATM, FDDI) vorfinden. Grafik 2 zeigt Ihnen die Schicht, in der SNMP zuhause ist, sowie die zugehörigen Protokolle der verschiedenen Schichten. SNMP ist eingebettet in Anwendungen, die wiederum in der application layer zu finden sind. SNMP benötigt die Dienste der presentation layer (ASN.1 und BER) um Management-Daten in eine netzwerkkompatible Form umzuwandeln, ohne Rücksicht darauf , um welches Netz es sich dabei handelt. UDP/IP wird von SNMP umfassend für den Transport und den network layer service genutzt.
7 | Application Layer | Management- und Agent-APIs |
SNMP | ||
6 | Presentation Layer | ASN.1 und BER |
5 | Session Layer | RCP und NetBios |
4 | Transport Layer | TCP und UDP |
3 | Network Layer | IP und IPX |
2 | Data Link Layer | Ethernet, ArcNet und Token Ring |
1 | Physical Layer |
SNMP und das OSI Modell (Grafik 2)
Daten passieren die verschiedenen Schichten des OSI Modells in diskreten Blöcken, genannt protocol data units (PDUs). Ein PDU ist eine logical designation (~Passier/Infoschein) für die Daten in einem Paket, das von einer speziellen OSI Schicht oder einem Protokoll gebraucht wird. So könnte z.B ein IP-Packet auf eine Netzwerk-PDU (NPDU) verweisen, ein UDP-Datagram auf ein Transport-PDU (TPDU) , und eine SNMP-Nachricht auf eine Application-PDU (APDU).
Bevor Daten über das Netzwerk gesendet werden können, müssen sie Stück für Stück in das jeweilige PDU-Format einer jeden Schicht, die sie passieren, gekapselt bzw. multigeplext werden. Jede neue PDU-Kapsel legt sich um die vorherige. Erst wenn dies erledigt ist, passieren die Daten die physical layer und werden in Netzwerk gesendet.
Wenn die Daten die Zieladresse erreicht haben, müssen sie wieder entkapselt bzw. demultigeplext werden, bevor sie verarbeitet werden können => während die Daten eine Schicht nach der anderen passieren, werden sie Stück für Stück entblättert. Die Informationen, die die PDUs enthalten, teilen den Protokollen der einzelnen Schichten mit, was sie mit den Daten machen sollen (error detection und correction, message routing, usw.)
Grafik 3 zeigt eine "eingehüllte" SNMP-Nachricht, die in einem Ethernet mit Hilfe von UDP/IP transportiert wird. Die äußerste Hülle teilt der data link layer mit, daß es eine Nachricht für das Ethernet ist. Die nächste Hülle (IP Packet), klärt den Weg der Nachricht, von Verteiler zu Verteiler, über das Netzwerk. Die UDP-Hülle weist dem richtigen Protokoll die Aufgabe zu, die Nachricht in Empfang zu nehmen. Die SNMP Nachricht wird als solche nicht nur durch den Ort ihres Empfangs erkannt, sondern auch durch ihren Inhalt. (Das in der Grafik 3 gezeigte cyclical redundancy checksum (CRC) erkläre ich später)
Eine SNMP Nachricht und ihre Netzwerk "Hülle" (Grafik 3)
In den meisten Fällen ist die PDU ein einfacher header block oder bzw. "Einleitung", in der einige Identifikations-Informationen, gefolgt von einem payload of data, enthalten sind. Die Payload ist ebenfalls eine PDU, die von der nächst höheren layer empfangen wird. Je mehr layer eine Nachricht passieren muss, umso größer ist die Zahl der header die ihr angefügt werden.
Wenn Sie z.B an einen Kollegen im nächsten Zimmer eine Nachricht mit dem Inhalt "Essen?" zusenden, werden nicht nur 6 Nachrichten-Bytes ins Netzwerk geleitet. Nein, eine Menge von Netzwerk-Kontrollinformationen (auch als "overhead" bekannt) müssen an Ihre Nachricht angefügt werden, damit sie ihr Ziel sicher und schnell erreicht.
Um herauszufinden was passiert wenn eine SNMP-Nachricht von einem host zum Anderen gesendet wird, müssen wir uns näher mit den PDUs befassen. Wir beschäftigen uns jetzt zuerst mal mit den PDU der data link, network und transport layer. Auf die presentation und application layer gehen wir ein, nachdem wir uns mit ASN.1 und SNMP Messages näher beschäftigen.
Alle Informationen die in einem Ethernet Netzwerk verkehren sind in einem Ethernet-Rahmen (Ethernet frame) eingekapselt. Ein Rahmen selbst ist eigentlich nur ein Datenpaket. Solche Pakete werden frames (Rahmen) genannt, da die speziellen synchronization and error detection bits den Daten voraus und hinterhergehen um sie zu "framen" (einzurahmen).
Digital Equipment Corporation, INTEL Corporation und Xerox Corporation entwickelten 1973 Ethernet (auch als DIX Ethernet Standard bekannt). IEEE verbesserte den DIX-Ethernet-Standard und veröffentlichten ihn 1983 als 802.3 Standard. Es gibt einige leichte Unterschiede zwischen den DIX und IEEE 802.3 Rahmen-Format, aber im wesentlichen sind sie dasselbe Netzwerk- Schnittstellenprotokoll.
Beide Rahmen-Formate besitzen eine spezielle Sequenz von Bits in der preamble (Einleitung), die vom Empfänger dazu benutzt wird, die Daten beim lesen zu synchronisieren. Diese preamble ist beim DIX Format acht Oktetten, beim IEEE 802.3 sieben Oktetten lang. Der 802.3 preamble folgt eine one-octet Bit Sequenz, genannt Start of Frame Delimiter (SFD), welche den Anfang eines jeden zu übertragenden Paketes kennzeichnet. Ein 32-Bit postamble, genannt die Frame Check Sequenz (FCS), beinhaltet eine 32 Oktetten lange CRC (Cyclic Redundant Checksum) , berechnet aus den Daten die im frame (Rahmen) enthalten sind. Das internationale Format beider Rahmen wird in der Grafik 4 abgebildet.
DIX Ethernet-Rahmen |
Größe | IEE 802.3 Ethernet-Rahmen | Größe |
Preamble
|
8 Oktetten | Preamble | 7 Oktetten |
Start of Frame Delimeter | 1 Oktette | ||
Source Address | 6 Oktetten | Source Address | 6 Oktetten |
Destination Address | 6 Oktetten | Destination Address | 6 Oktetten |
Protocol Type | 2 Oktetten | Protocol Type | 2 Oktetten |
Payload
|
0 bis 1500 Oktetten |
Payload | 0 bis 1500 Oktetten |
Padding | 0 bis 46 Oktetten |
Padding | 0 bis 46 Oktetten |
Frame Check Sequence | 4 Oktetten | Frame Check Sequence | 4 Oktetten |
Internationales Format der DIX und IEEE 802.3 Ethernet frames (Grafik 4)
Das source und destination Adressenfeld (Quell- und Zieladressverzeichnis) beinhaltet die MAC-Adresse des Senders und des Empfängers. Diese Felder sind gewöhnlich sechs Oktetten lang, aber IEEE 802.3 erlaubt auch zwei Oktetten große Felder.
Eine MAC-Adresse ist die feste Hardware-Adresse einer Netzwerkkarte (NIC), die in einem Netzwerkgerät bzw. Komponente installiert ist. Jede NIC hat eine einmalige 48-Bit MAC Adresse. Die ersten 24 Bit einer MAC Adresse sind als organizationally unique identifier oder OUI bekannt. Jede Firma, die Ethernet Netzwerkkarten herstellt, bekommt von der IEEE eine Reihe von einmaligen OUIs zugewiesen. Diese 24-Bit OUI, und eine eigens von der Firma erstellte 24 Nummer, wird zu einer 48-Bit Nummer zusammengefügt und jeder produzierten Karte fest eingeprägt. So können niemals zwei Netzwerkkarten in einem Ethernet-Netzwerk die gleiche MAC-Adresse haben.
Nach dem Adressenfeld folgt im DIX-Rahmen ein protocol type value, daß auf den richtigen Netzwerk Service zeigt, der die frames payload data bearbeiten soll. Für IP wäre dies 0x0800; für Novell NetWare 0x8138. Eine Liste aller Protokolle, die von Ethernet unterstützt werden, findet man in der RFC 1700.
Der 802.3-Rahmen nutzt nicht das gleiche Feld wie der DIX-Rahmen um den protocol type zu speichern, diese Information kann direkt aus den 802.3-payload data herausgelesen werden. Dafür werden in diesem Feld die Informationen über die Länge des vollständigen payload gespeichert. Mit Hilfe der Daten aus den type- und length-Feldern entscheidet die data link layer ob es sich um einen DIX-Rahmen oder einen IEEE 802.3-Rahmen handelt.
Die payload selbst ist ein Datenblock der zwischen einer Größe von 46 bis 1500 Oktetten schwankt. Jeder Rahmen sollte mindestens eine Länge von 64 Oktetten haben, damit der Ethernet Carrier Sense Multiple Access/Collision Detection mechanism (CSMA/CD) sicher arbeiten kann, und somit ein Minimum an Netzwerkperformance bietet. Wenn die payload data kleiner als 46 Oktetten ist, wird ein padding (Polsterung) angefügt, um auf die gewünschte Länge zu kommen. Das padding ist als ein Teil des payload anzusehen, jedoch nicht als ein Teil der payload data selbst.
Das payload eines DIC-Rahmen beinhaltet die IP und UDP-headers sowie die SNMP-Nachricht. Anders beim DIX-Rahmen. Hier befinden sich noch ein logical link control (LLC) header und ein sub-network access protocol (SNAP) header in der payload. Mit Hilfe dieser zusätzlicher Informationen werden die höher angesiedelten Protokolle, welche die Daten erzeugt haben, identifiziert. Diese header, sowie das ganze IEEE 802.3-Rahmenformat, werden im RFC 1024 beschrieben.
Dem payload folgt ein CRC-32 Wert, auch Frame Check Sequence (FCS) genannt. Dieses CRC-32 value (Wert) wurde aus dem ganzen Rahmen berechnet. Mit Hilfe dieses values (Wertes) kann der Empfänger feststellen, ob das Paket auf seinem Weg durch das Netzwerk beschädigt wurde. Beschädigte frames werden dann z.B. von Bridges oder Router aus dem Verkehr gezogen. Die preamable und das CRC value des Rahmen werden abgetrennt, bevor die payload information die network addressing layer erreicht.
2.7 Das IP Paket
Jedes Gerät in einem Netzwerk wird mit einer oder mehreren logischen Netzwerkadressen bezeichnet. Diese Adresse ist eine Beschreibung des Standortes dieses Gerätes in einem Netzwerk. Während eine MAC-Adresse fest in das Gerät geprägt wird, ist eine IP-Adresse in einem Speicher hinterlegt, und kann ohne Probleme geändert werden.
Die maximale Länge eines IP-packets, header eingeschlossen, beträgt 65535 Oktetten. Der header beinhaltet ein 16-Bit checksum value. Diese checksum zielt nur auf den IP header selbst, nicht auf die IP packet's data. Das checksum header field wird jedes Mal auf Null gesetzt, bevor eine checksum Berechnung ausgeführt wird.
Der IP header beinhaltet ein paar Daten und variiert in seiner Länge (siehe Grafik 5). Ich möchte nicht zu sehr auf den IP header eingehen (jedes TCP/IP Buch tut dies). Die einzigen Felder, die uns interessieren, sind das Source Address field (auch Source IP Address oder SIP genannt) und das Destination Address field (auch Target IP Address oder TIP genannt).
Control Information | 12 Oktetten |
Source Address | 4 Oktetten |
Destination Address | 4 Oktetten |
Options and Padding | Variable |
Payload | 0 bis 65515 Oktetten |
Format des Internet Protokoll Pakets (Grafik 5)
Datenpakete werden mit IP "umhüllt", um mit seiner Hilfe logisches adressieren zu ermöglichen. IP selber ist kein sicheres Protokoll. Das bedeutet, daß IP nicht für das Überbringen der Daten garantiert, sowie keine Fehlermeldung aufzeichnet, wenn z.B. Fehler im IP-Paket sind.
Die Internetprotokoll Version 4 (IPv4) wurde 1981 veröffentlicht und wird in der RFC 791 beschrieben. IPv4 ist momentan das weit verbreitetste network addressing protocol im Internet; es wird möglicherweise in der Zukunft vom IPv6 abgelöst (bekannt als Internet Protocol Next Generation oder IPNG).
Merkhilfe : Wie man aus dem Namen "Datagramm" schon heraushört, ist dieses Protokoll verbindungslos. Eselsbrücke : Datagramm ---- Telegramm |
Das User Datagram Protocol (UDP) ist ein connectless (verbindungsloses) transport protocol. Es ist in der TCP/IP Suite mit eingeschlossen und wird mit RFC 768 beschrieben. UDP wird speziell dafür genutzt, Nachrichten auf der Host-Ebene zu routen. Das bedeutet, daß die Informationen, die im UDP-"Umschlag" gespeichert werden, nur für den Host der sie absendet, sowie für den Host der sie empfängt, von Interesse sind. Die Netzwerkkomponenten, die sich zwischen den beiden Hosts befinden (Router, Bridges und Hubs), schenken den UDP-Transportinformationen keine Beachtung. UDP selber hat keine Ahnung von network addressing oder connections, es verlässt sich daher völlig auf IP, um seine Datagramms zwischen den Hosts zu bewegen.
Der UDP-header ist 8 Oktetten lang und beinhaltet die source und die destination port Adressen, die totale Länge des Datagramms und eine 16-Bit checksum value (siehe Grafik 6). Die port address (auch port numbers genannt) wird dazu genutzt, den network port des sendenden Hosts sowie des empfangenden Hosts zu ermitteln.
Source Port | 2 Oktetten |
Destination Port | 2 Oktetten |
Length | 2 Oktetten |
Checksum | 2 Oktetten |
Payload | 0 bis 65527 Oktetten |
Format des UDP-Datagramms (Grafik 6)
Die Länge des UDP-Datagramms bewegt sich zwischen 8 und 65535 Oktetten (je nach Umfang des payload). Mit Hilfe des checksum-Wertes kann überprüft werden, ob das Datagramm beschädigt ist. Wenn das checksum value auf Null gesetzt wird, ist der error checking mechanism ausgeschaltet, und die Verantwortung der Fehlersuche im datagram payload trägt voll und ganz die data link layer (in diesem Fall der CRC-Wert des Ethernet-Rahmen).
Wenn der checksum value nicht auf Null gesetzt wurde, und UDP eine Beschädigung am Datagramm festgestellt hat, teilt es dem application layer service genau die target port number mit, bei der der Fehler entdeckt wurde. Wenn der Fehler, auf eine von einem Management-System abgesendete SNMP Nachricht verweist, wird diese Nachricht herausgenommen und eine "retry" request message (das ist eine Nachricht, die um das nochmalige Senden des datagrams bittet) wird an den Agent gesendet.
Die destination (Bestimmungs-) port number ist der Schlüssel dafür, wie mit den Daten im UDP-Datagramm verfahren wird. Jede port number ist einem speziellen process layer service, wie z.B. Telnet, TFTP, oder SNMP, zugewiesen.
If it's unreliable, why bother ?
UDP wird oft als unreliable (unzuverlässiges) Protokoll beschrieben. Das Wort "unreliable" drückt aus, das UDP instabil und mangelhaft entwickelt wurde, dies ist jedoch nicht der Fall. Unreliable ist die Bezeichnung für alle verbindungslose Protokolle, da sie keine fehlerfreie Datenübertragung garantieren können.
Wenn man ein connectionless transport protocol für das Routen von Datenpaketen benutzt, wird man mit einem zur Hälfte organisierter, zur anderen Hälfte unorganisierter Verbund, konfrontiert. Jedes Paket wird unabhängig vom Anderen behandelt, es gibt keinen einheitlichen Weg der sich um das Routen der Pakete kümmert, die Pakete werden sprichwörtlich wie eine heiße Kartoffel von Knoten zu Knoten weitergereicht. Aus diesen Gründen, gibt es keine Garantie, daß die Daten Ihr Ziel erreichen.
Vergleichen Sie dies mit einem connection-oriented transport protocol (verbindungsorientierten Protokoll),
wie TCP.
TCP verfolgt die Spur eines jeden Protokolls, daß protocol handshaking mechanism
verwendet. Wenn ein Paket nicht an seiner Bestimmungsadresse angekommen ist, meldet TCP
sich bei dem Sender und bittet um ein erneutes Senden .
Die Pakete reisen also entlang einer speziellen Route vom Ursprung- zum Bestimmungsort, man könnte es mit einem Telefongespräch vergleichen, daß ebenso sorgfältig weitervermittelt wird. Ein verbindungsloses Protokoll kann man eher mit der Post vergleichen. Sie werfen Ihren Brief ein, ab dann garantiert Ihnen keiner mehr welchen Weg Ihr Brief nimmt, wie lange er dafür braucht und ob er überhaupt sein Ziel erreicht.
Bevor Sie die verbindungslose Protokolle vollständig aufgeben, sollten Sie wissen, daß die Serie von Internet-Protokollen darauf aus ist, jeden Möglichkeit Daten zu übertragen, ausschöpft. Pakete werden nicht gleich beim ersten Anzeichen von Widerspruch weggeworfen. Tatsache ist, ein Netzwerk ist erst dann wirklich unzuverlässig, wenn entweder ein Gerät im Netzwerk versagt oder die Netzwerkressourcen erschöpft sind. In diesem Fall wären dann so viele beschädigte Pakete im Netz unterwegs, daß selbst eine zuverlässige TCP-Verbindung versagen würde.
UDP wird oft in sicheren LANs, zum Versand von kleinen Datenpakete eingesetzt. Wenn 99,9 % aller Datenpakete unbeschädigt ankommen, wundert man sich, warum man seine Zeit und Bandbreite mit connection management und handshake belastet. UDP erlaubt eine größere Bandbreite zum Transport der Daten, opfert aber dafür die error correction. Es ist jedoch wahrscheinlicher, daß ein Netzwerk überlastet, als das UDP und IP versagen.
Wenn Sie UDP verwenden, können Sie ein protocol error checking und correcting mechanism nach eigenem ermessen benutzen. Unter SNMP ist es die Verantwortung des Netzwerk-Management-System, daß die SNMP-Nachricht Ihr Ziel erreicht. Wenn nach einer festgelegten Zeit keine Antwort vom Agent erfolgt, liegt es an dem Management-System weitere Schritte zu unternehmen. Dies könnte eine weitere Anfrage oder eine Fehlermeldung an den Administrator sein..
UDP ist also ein leichtgewichtiges, gut einsetzbares Transport Protokoll. Um ein Mechanismus robust und zuverlässig zu machen, werden mehr Codes benötigt, als dies bei UDP der Fall ist. TCP's "connect" Einrichtungen, wie transmission handshaking und data buffer management mechanism, kommen auf die Kosten von einem höheren "overhead", was zur Verringerung der Geschwindigkeit und zum Verbrauch von mehr Netzwerkressourcen führt.
Wenn Sie Daten mit UDP/IP versenden, stellen Sie sich vor, daß wären Päckchen und Briefe, die mit nahezu 100% Wahrscheinlichkeit von der Post weitergeleitet und abgeliefert werden, also nicht wie eine Nachricht in einer Flasche auf dem Ozean. Natürlich können einmal einzelne Datenpakete "untergehen", aber dann kann die network application immer noch Schritte zur Rückgewinnung starten.
2.9 Protocols, Ports, and Sockets
Ein Protokoll, daß durch ein Netzwerk "reist", wird von allen empfangsbereiten Komponenten untersucht. Wenn die destination address (Ziel-Adresse) nicht mit der des aktuellen Gerätes übereinstimmt, wird das Paket zum nächsten Host oder zum nächsten Router weitergeleitet. Wenn die Adresse übereinstimmt, hat das Paket sein Ziel erreicht und wird von den höher liegenden Layers im protocol stack verarbeitet. In den vorhergehenden Kapiteln haben wir schon besprochen, wie mit Hilfe der Informationen in den PDU-headers, die richtigen Protokolle und Dienste angesprochen werden. Nun wollen wir sehen, wie diese Informationen genutzt werden.
Protokoll-Nummern
Jeder header einer jeden network layer-PDU beinhaltet ein 8-Bit Wert, der zur Entscheidung genutzt wird, welches transport layer protocol die Bearbeitung des PDUs-payload übernehmen soll. Dieser Wert wird Protokoll-Nummer genannt.
Bei einem Windows NT System, wird das Transport-Protokoll in der c:\winnt\system32\drivers\etc\protocol-Datei definiert. Sie beinhaltet eine Tabelle, die jedes Protokoll, daß vom dem network stack des Hosts unterstützt wird, mit einem Namen und einer Nummer bezeichnet.
Wenn Sie genannten RFCs durchsehen, werden Sie feststellen, daß dort weit mehr Protokoll-Nummern beschrieben werden, als in dieser Datei aufgeführt sind. Es ist aber so, daß die meisten Hosts mit nur wenigen Protokollen auskommen, selbst diese Protokoll-Datei weist mehr Protokolle auf, als der Host (im Normalfall) benötigt.
Die network layer vergleicht die Protokoll-Nummern mit denen, die in der Protokoll-Datei aufgelistet sind, und entscheidet, welcher transport service die PDU weiterleitet. Bei der Protokoll-Nummer 6 wird TCP angesprochen, während eine SNMP Nachricht, die die Nummer 17 beinhaltet, auf UDP verweist.
Port-Nummern
Nachdem die PDU von der transport layer bearbeitet wurde, durchläuft sie die application layer zur abschließenden Bearbeitung. Application layer-Prozesse, die die PDUs "bearbeiten", werden "Netzwerk-Service" genannt, und durch ihre ihnen zugewiesenen Nummern identifiziert. Jede transport layer-PDU beinhaltet zwei 16-Bit Port-Nummern, die zum ersten den Quell-Port und zum zweiten den Ziel-Port, der die PDU verarbeitet bzw. bearbeiten soll, identifiziert. Diese Ports sind gewöhnlich auf zwei verschiedenen Hosts, jedoch kann ein Host auch an sich selber eine Netzwerknachricht senden.
Auf einem Windows NT-System werden die Netzwerk-Service in der c:\system32\drivers\etc\services-Datei beschrieben. Diese Datei ist der Struktur der Protokoll-Datei sehr ähnlich. Jede Zeile beinhaltet den Namen des network services, gefolgt von der Port-Nummer und dem dazugehörenden Transport-Protokoll.
Viele dieser Ports, die in der SERVICE FILE beschrieben werden, sind "well-known"-Ports (alt/gut-bekannte Ports), die in der zugewiesenen RFC-Nummer beschrieben werden. Ein well-known-Port ist stets einem bestimmten Netzwerk-Service zugewiesen, und wird von allen Netzwerk-Hosts als solcher erkannt. Dies erlaubt Anwendungen im voraus zu wissen, welcher Port zu nutzen ist, um ein bestimmtes Protokoll zu verwenden. Alle well-known-Ports befinden sich in einem Bereich von 1 bis 1023.
SNMP nutzt zwei well-known-Ports : 161 und 162.
Port 161 empfängt alle SNMP-Requests. Wenn ein Management-System eine SNMP-Request
an einen Agent versenden möchte, gibt es den Port 161 als Ziel-Port im UDP-header
an. Die SNMP-Response wird von dem Agent an den selben Port
zurückgesendet.
Port 162 ist der SNMP-Trap Port. Wenn ein SNMP-Agent ein Trap zu einem Management-System sendet, gibt es als Ziel-Port den Port 162 an.
Sockets
Well-known-Port-Nummern werden von Programmieren als "statically allocated" bezeichnet. Um Kontakt zu "Dynamischen Ports" zu bekommen, werden Sockets benötigt. Eine Socket besteht aus einer Kombination von Port-Nummern, Protokoll-Nummern und Netzwerk-Adressen, die wiederum den Endpunkt einer Netzwerkverbindung bilden. Um ein Socket zu bilden, müssen Netzwerk-Adresse und Transport-Service genau beschrieben sein, eine Port Nummer zugewiesen werden, und ein handle oder descriptor zum Socket ist zurückgekehrt. Alle dynamischen Ports bekommen eine Nummer zwischen 1024 und 65535 zugewiesen.
Vielleicht ein Beispiel, damit es etwas ersichtlicher wird.
Wenn Sie eine SNMP Nachricht an einen Host mit der IP Adresse von 192.168.0.10 versenden wollen, würden Sie ein Socket mit den folgenden Parametern bilden. 192.168.0.10 ,17 (UDP) und 161. Alle Daten, die Sie mit diesem Socket versenden, werden von dem Host mit der IP-Adresse 192.168.0.10 am Port 161 mit dem UDP-Transportprotokoll, empfangen
Unter Windows werden die Sockets von der Winsock-API erschaffen. Beide, SNMP-Service und SNMP-Trapservice, benutzen Winsock, um Nachrichten zu empfangen oder zu versenden.
Grafik 7 zeigt drei verschiedene Sockets, die von einem SNMP Management-Prozess bzw. SNMP Agent-Prozess gebildet und zwischen den beiden über das Netzwerk gesendet werden.
Sockets, die von einem SNMP Management- System und einem Agent genutzt werden (Grafik 7)
Socket-Paar A zeigt wie das Management-System eine SNMP Request-Nachricht an einen SNMP-Agent verschickt.
Socket-Paar B zeigt die Response-Nachricht des Agents an das Management-System.
Socket-Paar C zeigt wie ein Agent ein Trap an das Management-System sendet