March 28, 2026

3.5 Datenkommunikation über mehrere Schichten: Ein einfaches Praxisbeispiel

Datenkommunikation in Netzwerken wirkt für viele Einsteiger zunächst abstrakt, weil mehrere Protokolle, Adressen, Geräte und Schichten gleichzeitig zusammenarbeiten. In der Praxis geschieht jedoch nichts Magisches: Wenn ein Benutzer eine Website aufruft, durchlaufen die Daten nacheinander verschiedene Ebenen der Kommunikation. Jede Schicht übernimmt dabei eine klar definierte Aufgabe. Anwendungen erzeugen die Anfrage, Transportprotokolle organisieren die Verbindung, IP sorgt für logische Adressierung und Routing, Switches leiten Frames lokal weiter und das physische Medium transportiert die Signale bis zum Ziel. Genau dieses Zusammenspiel über mehrere Schichten ist der Kern moderner Netzwerkkommunikation. Wer Netzwerke wirklich verstehen will, muss daher nicht nur einzelne Begriffe wie TCP, IP, MAC-Adresse oder DNS kennen, sondern nachvollziehen können, wie diese Bausteine in einem realistischen Ablauf zusammenwirken.

Table of Contents

Warum ein Praxisbeispiel für Datenkommunikation so wichtig ist

Viele Netzwerkthemen werden isoliert gelernt: DNS hier, TCP dort, Routing an anderer Stelle. Im echten Netzwerkbetrieb greifen diese Mechanismen aber immer ineinander. Genau deshalb ist ein durchgehendes Praxisbeispiel besonders hilfreich. Es zeigt, dass eine einfache Benutzeraktion im Hintergrund mehrere Schichten des OSI- oder TCP/IP-Modells gleichzeitig nutzt.

Was ein gutes Praxisbeispiel sichtbar macht

Wie aus einer Benutzeraktion technische Kommunikation entsteht
Welche Protokolle an welcher Stelle beteiligt sind
Wie Switches, Router und Server zusammenarbeiten
Warum Fehler auf verschiedenen Schichten auftreten können
Wie Kapselung und Entkapselung in der Praxis funktionieren

Ein solches Schichtverständnis ist besonders wichtig für CCNA-Einsteiger, weil viele spätere Themen wie Routing, VLANs, NAT, ACLs oder DNS direkt darauf aufbauen.

Das Ausgangsszenario: Ein Client ruft eine Website auf

Für dieses Praxisbeispiel betrachten wir einen typischen Ablauf in einem Unternehmensnetzwerk. Ein PC im Benutzer-VLAN möchte mit dem Browser eine interne oder externe Website öffnen. Der Benutzer gibt einen Namen ein, zum Beispiel www.firma.local oder www.beispiel.de. Der Rechner muss nun diese Anfrage technisch verarbeiten und über mehrere Schichten hinweg an den Zielserver schicken.

Vereinfachte Netzumgebung

Ein Client-PC mit IP-Adresse im Netz 192.168.10.0/24
Ein Access-Switch im lokalen LAN
Ein Router oder Layer-3-Switch als Default Gateway
Ein DNS-Server zur Namensauflösung
Ein Webserver im lokalen Rechenzentrum oder im Internet

Beispielhafte Adressen im Szenario

Client: 192.168.10.20
Default Gateway: 192.168.10.1
DNS-Server: 192.168.20.53
Webserver: 192.168.30.80 oder externe öffentliche IP

Dieses Szenario ist bewusst einfach gehalten, enthält aber bereits alle wesentlichen Elemente moderner Datenkommunikation.

Schritt 1: Die Anfrage entsteht auf Anwendungsebene

Am Anfang steht nicht das Netzwerk selbst, sondern eine Benutzeraktion. Der Benutzer öffnet einen Browser und gibt eine URL ein. Auf Anwendungsebene erzeugt der Browser daraus eine Anfrage, die später per HTTP oder HTTPS an einen Webserver gesendet werden soll.

Was auf dieser Ebene passiert

Der Benutzer startet eine Anwendung
Die Anwendung erzeugt eine Anfrage an einen Dienst
Das Ziel ist zunächst oft nur als Name bekannt, nicht als IP-Adresse

Diese Ebene entspricht im OSI-Modell hauptsächlich Layer 7, im TCP/IP-Modell der Anwendungsschicht. Hier entstehen die eigentlichen Nutzdaten der Kommunikation.

Warum an dieser Stelle noch keine Verbindung besteht

Der Browser kennt zu Beginn meist nur den Domainnamen. Bevor Daten an den Webserver gesendet werden können, muss zunächst eine Namensauflösung erfolgen. Genau dadurch wird sichtbar, dass Anwendungen allein keine Netzkommunikation vollständig abwickeln, sondern andere Schichten und Dienste benötigen.

Schritt 2: Namensauflösung über DNS

Damit der Client weiß, wohin die Anfrage gesendet werden muss, benötigt er die IP-Adresse des Zielservers. Dafür nutzt er DNS, das Domain Name System. Der Client sendet also zuerst eine DNS-Anfrage an den konfigurierten DNS-Server. Erst nach dieser Auflösung kann die eigentliche Webverbindung beginnen.

Was DNS in diesem Ablauf leistet

Übersetzung des Namens in eine IP-Adresse
Bereitstellung einer technischen Zieladresse für die weitere Kommunikation
Trennung von benutzerfreundlichen Namen und logischen Netzwerkadressen

Welche Schichten dabei beteiligt sind

DNS ist auf Anwendungsebene ein Dienst. Für die Übertragung nutzt die Anfrage in der Regel UDP auf Port 53, also die Transportschicht. Darunter wird das Paket mit IP versehen und lokal per Ethernet oder WLAN transportiert. Schon an diesem ersten Teilschritt zeigt sich, wie mehrere Schichten gleichzeitig zusammenspielen.

Ein Benutzer oder Administrator könnte die Namensauflösung beispielsweise so prüfen:

PC> nslookup www.firma.local
PC> nslookup www.beispiel.de

Schritt 3: Der Client prüft, wo sich das Ziel befindet

Nachdem der Client die Ziel-IP-Adresse kennt, muss er entscheiden, ob sich das Ziel im selben Subnetz befindet oder ob ein Router benötigt wird. Diese Entscheidung erfolgt mithilfe der eigenen IP-Adresse und Subnetzmaske.

Lokales Ziel oder entferntes Ziel

Liegt das Ziel im selben Subnetz, erfolgt direkte lokale Zustellung
Liegt das Ziel in einem anderen Netz, wird das Default Gateway verwendet

In unserem Beispiel liegt der DNS-Server oder Webserver häufig in einem anderen Netz. Der Client erkennt daher, dass das Paket nicht direkt an den Zielhost, sondern zunächst an das Gateway geschickt werden muss.

Warum dieser Schritt so wichtig ist

Viele Einsteiger glauben, ein Client sende Pakete direkt an jedes Zielsystem. Tatsächlich wird bei entfernten Netzen zunächst nur das nächste Layer-3-Gerät im lokalen Segment adressiert. Genau dadurch funktioniert Routing über mehrere Netzwerke hinweg.

Schritt 4: Auflösung der Ziel-MAC-Adresse mit ARP

Nun kennt der Client zwar die Ziel-IP des DNS-Servers oder des Gateways, aber noch nicht die zugehörige MAC-Adresse im lokalen Netz. Für diese Zuordnung nutzt IPv4 das Address Resolution Protocol, kurz ARP. Der Client sendet eine Broadcast-Anfrage ins lokale Segment: „Wer hat die IP-Adresse 192.168.10.1?“ Das Gateway antwortet mit seiner MAC-Adresse.

Was ARP in diesem Ablauf macht

Zuordnung einer bekannten IPv4-Adresse zu einer MAC-Adresse
Aufbau der Grundlage für lokale Ethernet-Kommunikation
Nutzung eines Broadcasts innerhalb der Broadcast-Domäne

Warum ARP ein gutes Beispiel für Schichtzusammenspiel ist

ARP zeigt besonders gut, dass IP-Kommunikation nicht ohne Layer-2-Zustellung funktioniert. Auch wenn der eigentliche Zielserver weit entfernt ist, muss der Client lokal immer zunächst wissen, an welche MAC-Adresse der nächste Frame gesendet werden soll.

Typische Prüfbefehle dafür sind:

PC> arp -a
Router# show arp
Switch# show mac address-table

Schritt 5: Aufbau der Transportverbindung

Sobald die Ziel-IP feststeht, beginnt die eigentliche Verbindung zum Webserver. Wenn eine Website per HTTP oder HTTPS aufgerufen wird, nutzt der Client normalerweise TCP als Transportprotokoll. TCP sorgt dafür, dass Daten zuverlässig, geordnet und kontrolliert zwischen Client und Server ausgetauscht werden.

Was TCP in diesem Schritt übernimmt

Aufbau einer Verbindung zwischen Client und Server
Zuordnung der Kommunikation über Portnummern
Sicherstellung von Reihenfolge und Vollständigkeit
Fehlerbehandlung und Wiederholung verlorener Segmente

Der TCP-Three-Way Handshake

Vor der eigentlichen Datenübertragung wird bei TCP eine Sitzung aufgebaut. Dieser Verbindungsaufbau erfolgt klassisch über SYN, SYN-ACK und ACK. Erst danach sendet der Client die eigentliche HTTP- oder HTTPS-Anfrage.

Client sendet SYN
Server antwortet mit SYN-ACK
Client bestätigt mit ACK

Dieses Verhalten gehört zur Transportschicht und ist ein zentrales Beispiel dafür, wie Transportlogik unabhängig von Routing oder Ethernet funktioniert.

Schritt 6: Kapselung der Daten über mehrere Schichten

Damit die Anfrage tatsächlich versendet werden kann, wird sie schrittweise gekapselt. Jede Schicht ergänzt Informationen, die für ihre Aufgabe notwendig sind. So entstehen aus Anwendungsdaten transportfähige Einheiten.

Wie Kapselung im Beispiel abläuft

Die Anwendung erzeugt die Webanfrage
TCP ergänzt Quell- und Zielport
IP ergänzt Quell- und Ziel-IP-Adresse
Ethernet ergänzt Quell- und Ziel-MAC-Adresse
Layer 1 überträgt die Bits physisch

Was sich auf dem Weg ändert und was nicht

Besonders wichtig ist: Die Ziel-IP des Endziels bleibt erhalten, solange das Paket unterwegs ist. Die MAC-Adressen im Ethernet-Frame ändern sich dagegen von Hop zu Hop, weil jeder Router einen neuen Frame für das nächste Segment erzeugt.

Schritt 7: Lokale Weiterleitung durch den Switch

Der fertige Ethernet-Frame wird zunächst an den lokalen Switch gesendet. Der Switch arbeitet auf Layer 2 und prüft die Ziel-MAC-Adresse. Anhand seiner MAC-Adress-Tabelle entscheidet er, an welchen Port der Frame weitergeleitet werden muss.

Aufgaben des Switches in diesem Ablauf

Empfang des Frames auf einem Access-Port
Prüfung der Ziel-MAC-Adresse
Gezielte Weiterleitung an den richtigen Port
Arbeiten innerhalb des passenden VLANs

Wichtige Layer-2-Prüfbefehle

Switch# show mac address-table
Switch# show vlan brief
Switch# show interfaces status

Wenn ein Problem auf dieser Ebene vorliegt, etwa ein falsches VLAN oder ein inaktiver Port, funktioniert die Kommunikation nicht, auch wenn TCP und IP korrekt wären.

Schritt 8: Routing durch das Default Gateway

Wenn das Ziel nicht im lokalen Subnetz liegt, gelangt der Frame zum Router oder Layer-3-Switch. Dort wird der Layer-2-Frame entfernt, das IP-Paket geprüft und die Routing-Tabelle ausgewertet. Der Router entscheidet, welcher Pfad zum Zielnetz führt, und kapselt das Paket für das nächste Segment neu ein.

Was der Router konkret macht

Entfernen des empfangenen Layer-2-Headers
Prüfen der Ziel-IP-Adresse
Suchen des besten Pfads in der Routing-Tabelle
Erzeugen eines neuen Frames für das nächste Segment

Typische Router-Befehle zur Analyse

Router# show ip route
Router# show ip interface brief
Router# traceroute 192.168.30.80

Diese Befehle helfen zu prüfen, ob das Zielnetz bekannt ist und über welchen Weg die Daten weitergeleitet werden.

Schritt 9: Ankunft am Zielserver und Entkapselung

Nachdem das Paket über lokale und gegebenenfalls mehrere geroutete Segmente transportiert wurde, erreicht es den Zielserver. Dort läuft der Prozess umgekehrt ab. Der Server entkapselt die Daten schrittweise: zunächst der lokale Frame, dann das IP-Paket, dann das TCP-Segment. Schließlich werden die Nutzdaten an den Webdienst übergeben.

Was am Ziel passiert

Die Netzwerkschnittstelle empfängt den Frame
Die Ziel-MAC wird geprüft
Das IP-Paket wird an den IP-Stack übergeben
TCP ordnet das Segment dem richtigen Port zu
Die Anwendung verarbeitet die Webanfrage

Warum Entkapselung wichtig ist

Erst durch Entkapselung wird aus dem transportierten Paket wieder eine verständliche Anwendungskommunikation. Ohne diesen Prozess könnte der Webserver die Anfrage nicht als HTTP- oder HTTPS-Aufruf erkennen.

Schritt 10: Die Antwort läuft denselben Weg zurück

Der Server erstellt nun eine Antwort, etwa den HTML-Inhalt der Website. Diese Antwort wird wiederum durch mehrere Schichten gekapselt und über Router, Switches und lokale Segmente zurück zum Client gesendet. Aus Netzwerksicht ist die Kommunikation also bidirektional und nutzt dieselben Grundlagen in beide Richtungen.

Was auf dem Rückweg gleich bleibt

Die Schichtlogik bleibt identisch
Die Antwort wird ebenfalls gekapselt und entkapselt
Routing und lokale Zustellung erfolgen erneut schichtweise

Was sich auf dem Rückweg ändert

Quell- und Zieladressen werden vertauscht
Die Antwortdaten unterscheiden sich von der Anfrage
Je nach Pfad und Routing können Zwischenschritte variieren

Welche Schichten sind in diesem Beispiel tatsächlich beteiligt?

Dieses einfache Webbeispiel zeigt, dass praktisch alle zentralen Schichten der Netzwerkkommunikation beteiligt sind. Selbst bei einer scheinbar simplen Benutzeraktion müssen mehrere Ebenen korrekt zusammenarbeiten.

Beteiligte Ebenen im Überblick

Anwendungsebene: Browser, DNS, HTTP, HTTPS
Transportebene: TCP oder für DNS oft UDP
Netzwerkebene: IP und Routing
Sicherungsebene: Ethernet, VLAN, MAC-Adressen
Bitübertragungsebene: Kabel, Glasfaser oder WLAN

Was das für Einsteiger besonders wichtig macht

Viele Fehlerbilder lassen sich nur dann korrekt verstehen, wenn klar ist, dass mehrere Schichten gleichzeitig beteiligt sind. Ein funktionierender Ping bedeutet zum Beispiel nicht automatisch, dass auch DNS, TCP-Port 443 oder die Webanwendung selbst funktionieren.

Wie hilft dieses Beispiel beim Troubleshooting?

Gerade im Troubleshooting ist ein solches Praxisbeispiel besonders wertvoll, weil es typische Prüfstationen sichtbar macht. Wenn eine Website nicht erreichbar ist, kann die Analyse entlang des Datenwegs erfolgen.

Typische Prüffragen entlang der Schichten

Ist das Interface physisch aktiv?
Ist der Client im richtigen VLAN?
Hat der Client eine gültige IP-Adresse?
Ist das Default Gateway erreichbar?
Funktioniert DNS?
Existiert eine Route zum Ziel?
Ist der Zielport erreichbar?
Läuft die Anwendung auf dem Server?

Typische Diagnosebefehle im Gesamtzusammenhang

PC> ipconfig /all
PC> ping 192.168.10.1
PC> nslookup www.firma.local
PC> tracert 192.168.30.80

Switch# show vlan brief
Switch# show mac address-table

Router# show ip route
Router# show arp

Diese Befehle decken mehrere Schichten ab und helfen dabei, den Datenweg methodisch nachzuvollziehen.

Welche typischen Fehler können in diesem Ablauf auftreten?

Das Praxisbeispiel ist auch deshalb so lehrreich, weil an nahezu jeder Stelle ein Fehler auftreten kann. Genau diese Vielfalt zeigt, wie wichtig ein strukturiertes Schichtverständnis ist.

Mögliche Fehler auf verschiedenen Ebenen

Defektes Kabel oder deaktivierter Port auf Layer 1
Falsches VLAN oder MAC-Lernproblem auf Layer 2
Fehlende IP-Adresse oder falsches Gateway auf Layer 3
Fehlende Route auf dem Router
DNS löst den Namen nicht korrekt auf
TCP-Port ist blockiert oder Anwendung lauscht nicht
Firewall oder ACL verhindert die Verbindung

Warum Ping allein nicht ausreicht

Ein erfolgreicher Ping prüft nur einen Teil der Gesamtkommunikation, meist auf IP-Ebene. Eine Website kann trotzdem ausfallen, wenn DNS, TCP-Port 443 oder die Anwendung selbst nicht funktionieren. Genau deshalb muss Netzwerkdiagnose immer mehrschichtig gedacht werden.

Warum dieses Praxisbeispiel für CCNA und Netzwerktechnik so wichtig ist

Dieses einfache Beispiel macht sichtbar, dass Netzwerke nicht aus isolierten Einzelthemen bestehen. Routing, Switching, ARP, DNS, TCP, IP und Anwendungen sind keine getrennten Inseln, sondern Teil eines einzigen Kommunikationsablaufs. Genau dieses Verständnis ist für CCNA-Einsteiger und für die Praxis entscheidend.

Was man aus dem Beispiel unbedingt mitnehmen sollte

Netzwerkkommunikation läuft immer über mehrere Schichten gleichzeitig
Jede Schicht hat eine klar definierte Aufgabe
Switches, Router und Server erfüllen unterschiedliche Rollen
DNS, ARP, TCP und IP greifen direkt ineinander
Fehlersuche funktioniert nur mit einem mehrschichtigen Verständnis

Genau deshalb ist ein durchgehendes Praxisbeispiel so wertvoll: Es zeigt nicht nur, wie Daten technisch transportiert werden, sondern auch, wie man moderne Netzwerke wirklich versteht. Wer diesen Ablauf sauber nachvollziehen kann, besitzt ein belastbares Fundament für Routing, Switching, Security und alle weiteren Themen der professionellen Netzwerktechnik.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

Professionelle Konfiguration von Routern und Switches
Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen
Erstellung von Topologien und Simulationen in Cisco Packet Tracer
Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG
Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible
Erstellung von Skripten für wiederkehrende Netzwerkaufgaben
Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege
Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.