Hallo zusammen, ich lerne gerade für die Schule das Thema Feldbussysteme. Dabei kommt im Script immer wieder das ISO-OSI Referenzmodell vor. Da wir aufgrund von Corona nur 3 Schulstunden hatten und bereits 5 Tage später (schon am Montag) die Abschlussklausur schreiben, kann ich meinem Lehrer keine Fragen stellen. Leider eine sehr unglückliche Situation. Im Script geht er immer wieder auf das ISO-OSI Referenzmodell ein. Er sagt, ALLE Protokolle halten sich an den Standard und lassen sich darin einordnen, zumindest Layer 7, 2 und 1 während ausnahmslos ausgeprägt. Auch bei I2C oder SPI. Da im Script keinerlei Erklärung zu den Schichten gemacht wird (nur deren Namen), lese ich dazu viel im Internet. Irgendwie habe ich aber das Gefühl, dass dieses Modell sich nur auf Netzwerke (Internet) bezieht. Jede Schicht fügt wohl irgendwelche Informationen hinzu. Letztendlich wird immer wieder erwähnt, dass sich alle daran halten und so eine Kommunikation über alle Hersteller und Protokolle hinweg ermöglicht wird. Alle Schichten seien zueinander kompatibel. Mir ist einfach nicht ganz klar, WAS dieses Modell eigentlich beschreibt. Alle Erklärungen sind einfach so allgemein gehalten, ich finde keine Informationen was in den Schichten physikalisch geschieht. Kurzum: Ist das eine Norm, die sagt das Byte muss so und so aufgebaut sein? Oder nur ein theoretisches Modell das sagt: Wir brauchen XYZ, ohne jede Spezifikation? Ich habe keine Ahnung welchen Vorteil mir das Modell bringen soll und wie es die Kommunikation zwischen verschieden Protokollen ermöglichen kann? Habt ihr ein paar Sätze dazu, die mich weiterbringen? Ich will keine vorgekaute Erklärung, nur eine kurze Info um meinen Knoten im Gehirn aufzulösen. Danke!
Fabian schrieb: > Kurzum: Ist das eine Norm, die sagt das Byte muss so und so aufgebaut > sein? Oder nur ein theoretisches Modell das sagt: Wir brauchen XYZ, ohne > jede Spezifikation? Ich habe keine Ahnung welchen Vorteil mir das Modell > bringen soll und wie es die Kommunikation zwischen verschieden > Protokollen ermöglichen kann? Es ist ein theoretisches Modell. Vergleichbar mit einem Schichtenmodell (Achtung: wie immer unpassender Autovergleich) für Fortbewegungsmittel. Da brauche ich auch ein Medium, einen Antrieb, Routenführung usw. Im Idealfall kann ich die einzelnen Teile unabhängig voneinander austauschen: Auto kann auf Feldweg oder Autobahn fahren; Ethernet geht über Kupfer, Glasfaser, Funk... Aber das Modell ist nur eine Möglichkeit das abzubilden, nicht die einzig echte Wahrheit. Und wie auch beim Auto das Medium "Luft" nicht wirklich funktioniert wie beim Flugzeug, ist auch die einzelne Austauschbarkeit der Schichten (deren Trennung manchmal auch nicht ganz scharf ist) in der Realität nur eingeschränkt möglich.
Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet" bzw. die damit verbundenen Protokolle folgen strikt dem OSI-Schichtenmodell. Es gab vor ewiger Zeit mal den Versuch, das OSI-Protokoll auf Basis des OSI-Schichtenmodells zu implementieren, aber das ging kräftig in die Hose. Einzelne Fragmente daraus haben aber bis heute überlebt und wurden an andere Protokollfamilien adaptiert, z.B. X.500 als LDAP und X.509 für die Verwaltung kryptografischer Schlüssel. X.400 für E-Mail existiert noch, hat aber seinen Zenith auch schon seit über zwanzig Jahren überschritten. Leider wird immer wieder auf Krampf versucht, jegliche geschichteten Protokolle in das OSI-Modell zu pressen, aber wie heißt es doch so schön: "Nicht alles, was hinkt, ist ein Vergleich."
Fabian schrieb: > ich > finde keine Informationen was in den Schichten physikalisch geschieht. Nur in Schicht 1 passiert etwas physikalisches. Deshalb heißt sie auch so.
"Layer 1, Physical, dient lediglich dazu, ein Bit von A nach B zu bekommen. Zur Not kann man dafür auch rhythmisch an einer Schnur ziehen ..."
Jan H. schrieb: > Es ist ein theoretisches Modell. OK, der Vergleich passt aber für mich. Es wird darin also nur festgelegt, das man etwas benötigt um XYZ zu machen. Ala: Wenn du sprechen willst, mach zuerst den Mund auf usw. Das mag ja als Entwickler bei Neuentwicklungen hilfreich sein, aber ich verstehe einfach nicht warum es scheinbar so immens wichtig ist, Profibus oder andere Busse in diese Schichten zu zerlegen. Laut unserem Lehrer würde dadurch die Fehlersuche vereinfacht. Bleibt nur die Frage wie und warum? Die Doku des Busses hilft mir dabei sicher weiter, das reine Modell doch eher nicht. Ich sehe einfach keinen Sinn in diesem Modell. Andreas S. schrieb: > Die Aussage des Lehrers ist großer Unsinn. Danke ;) > Leider wird immer wieder auf Krampf versucht, jegliche geschichteten > Protokolle in das OSI-Modell zu pressen, aber wie heißt es doch so > schön: "Nicht alles, was hinkt, ist ein Vergleich." Und damit habe ich ein Problem :) Denn was hilft es, wenn ich I2C in diese Schichten zerlege?
Andreas S. schrieb: > Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet" > bzw. die damit verbundenen Protokolle folgen strikt dem > OSI-Schichtenmodell. Das kann man so nicht stehen lassen. Richtig ist, dass IP und darauf aufbauende Protokolle nicht entsprechend des OSI-Modells designed wurden. Aber: man kann sie rückwärts durchaus weitgehend in die OSI-Schichten einordnen. Nur einige wenige Protokolle sind auf zwei benachbarten Schichten des OSI-Modells beheimatet und widersetzen sich dadurch einer eindeutigen Zuordnung. Es ist allerdings ziemlich bezeichnend, dass gerade diese Protokolle wiederum nur Hilfsprotokolle der IP-Protokollfamilie darstellen. Man könnte die Sache also auch so formulieren: IP und friends ist "quick and dirty" spezifiziert. Ohne saubere Schichten. Einfach nur so, dass es auf Basis der damaligen Verhältnisse einfach erstmal nur funktioniert... > Leider wird immer wieder auf Krampf versucht, jegliche geschichteten > Protokolle in das OSI-Modell zu pressen Weil es immer sinnvoll ist, sauber getrennte Protokollschichten zu haben.
Fabian schrieb: > aber ich > verstehe einfach nicht warum es scheinbar so immens wichtig ist, > Profibus oder andere Busse in diese Schichten zu zerlegen. Profibus ist auch ein eher schlechtes Beispiel, weil es die meisten Schichten in PB nicht gibt, wie du ja bereits erkannt hast. > Laut unserem > Lehrer würde dadurch die Fehlersuche vereinfacht. Naja. Es geht bei PB ja nur darum zu unterscheiden, was auf dem physischen Kabel passiert (Schicht 1), was auf der untersten MAC-Schicht passiert (Schicht 2) und welche Anwendungsdaten über dieses System übertragen werde (Schicht 7). Diese Schichten sind im theoretischen Modell vollständig unabhängig und können beliebig ausgetauscht werden, ohne das Gesamtsystem zu beeinflussen. In der Praxis funktioniert das auch an einigen Stellen, aber nicht immer und überall. Bei PB sind die Schichten tatsächlich weitgehend unabhängig. Es kann schon bei der Fehlersuche helfen, wenn man weiß, wie z.B. auf dem Bus addressiert und arbitriert wird und dass auf der Schicht 2 und 1 passiert. Denn wenn man ein Problem nur auf der Anwendungsebene (7) mit den Nutzdaten hat, dann hat das wahrscheinlich nichts mit Ebene 1 und 2 zu tun. Das meint dein Lehrer wahrscheinlich damit. Unterm Strich ist das Modell aber überbewertet, weil die praktischen Umsetzungen alle mehr oder weniger davon abweichen.
Andreas S. schrieb: > Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet" > bzw. die damit verbundenen Protokolle folgen strikt dem > OSI-Schichtenmodell. Das wollte ich auch gerade schreiben. Die Aussage des Lehreres ist definitiv falsch. @TS TCP/IP ist nie auf Basis des OSI Schichtenmodells enstanden, sondern entstand direkt aus der Praxis weil sich einer hingesetzt hat und einfach gemacht hat. Später hat man dann versucht TCP/IP irgendwie rückwirkend ins OSI Schichtenmodell einzupassen, so richtig passt es aber nicht. Ein Blick in die beiden Wikipediaartikel zeigt auch warum. > Es gab vor ewiger Zeit mal den Versuch, das > OSI-Protokoll auf Basis des OSI-Schichtenmodells zu implementieren, aber > das ging kräftig in die Hose. > ... > Leider wird immer wieder auf Krampf versucht, jegliche geschichteten > Protokolle in das OSI-Modell zu pressen, aber wie heißt es doch so > schön: "Nicht alles, was hinkt, ist ein Vergleich." Genau so ist es.
Nano schrieb: > Später hat man dann versucht TCP/IP irgendwie rückwirkend ins OSI > Schichtenmodell einzupassen, so richtig passt es aber nicht. TCP/IP sind aber nur ein Teil des Modells. Auch wenn sie sich eine Adressierung teilen und deshalb nicht unabhängig sind, kann man die restlichen Schichten (1, 2, 5, 6, 7) beliebig austauschen. Ob du über Ethernet (1+2), WLAN (1+2) oder Buschfunk (1+2) ins Internet gehst, spielt keine Rolle. Genau so kann man die oberen Schichten austauschen. Auch einzeln.
Nano schrieb: > Andreas S. schrieb: >> Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet" >> bzw. die damit verbundenen Protokolle folgen strikt dem >> OSI-Schichtenmodell. > > Das wollte ich auch gerade schreiben. > Die Aussage des Lehreres ist definitiv falsch. > > @TS Blödsinn hoch 10! Ich finde es äußerst beschämend so über eine Person zu urteilen die sich hier nicht geäußert hat! Wenn hier dumme Personen im Forum nachfragt dann hat er selber Probleme um Verstaendnis. Das hat nichts mit dem Lehrpersonal zu tun.
Fabian schrieb: > Das mag ja als Entwickler bei Neuentwicklungen hilfreich sein, aber ich > verstehe einfach nicht warum es scheinbar so immens wichtig ist, > Profibus oder andere Busse in diese Schichten zu zerlegen. > ... > Laut unserem > Lehrer würde dadurch die Fehlersuche vereinfacht. Bleibt nur die Frage > wie und warum? Wenn du eine ein neues Protokoll bspw. in der Bitübertragunsgschith (Schicht 1) oder Sicherungsschicht (Schicht 2) oder bzw. Netzzugangsschicht einführst und dieses zum Schichtenmodell kompatibel machst, dann kannst du alle darüber liegenden Protokolle in den höheren Schichten darüber laufen lassen ohne groß diese selbst schreiben zu müssen oder Änderungen vornehmen zu müssen. Wenn du also mal angenommen eine Leitung zu deinem Gartenhäuschen im Garten baust und dir dafür ein neues Protokoll für einen unüblichen Übertragungsweg ausdenkst. Z.b. Blitzlicht vom Wohnzimmerfenster ins Gartenhäuschen und zurück und du dieses Protokoll dann Kompatibel zum OSI Modell machst. Dann kannst du darüber die Protokolle in den höheren Schichten transportieren und somit alle Netzwerksoftware und Protokolle nutzen ohne groß an diesen Änderungen vornehmen zu müssen. Du könntest also bspw. Webseiten an dein Notebook im Gartenhäusschen über dein Blitzlich übertragen ohne einen Browser selber schreiben zu müssen, da HTTP in der Anwendungsschicht liegt und auf Schicht 6 aufbaut, welche wiederum auf Schicht 5 aufbaut und die Software aus dieser Kategorie verwendet. Das geht so weit runter bis zu der Schicht in dem dein Protokoll gültig ist und nur für dieses müsstest du dann Treiber schreiben. Alles andere kannst du somit wiederverwenden und das senkt dann auch die Fehlersuche im Protokoll. Denn wenn bspw. eine ssh Verbindung über dein Protokoll gut funktioniert, dann kannst du davon ausgehen, dass es kaum noch Fehler enthält.
Versteher schrieb: > Ich finde es äußerst beschämend so über eine Person zu urteilen die sich > hier nicht geäußert hat! Es wurde nicht über eine Person geurteilt, sondern es wurde eine Aussage dieser Person bewertet. Das ist ein Unterschied. Dass sich die allgemein "im Internet" verwendeten Protokolle strikt an das Modell halten, ist eben sachlich falsch. Das hat mit der Person gar nichts zu tun.
Versteher schrieb: > Nano schrieb: >> Andreas S. schrieb: >>> Die Aussage des Lehrers ist großer Unsinn. Nicht einmal "das Internet" >>> bzw. die damit verbundenen Protokolle folgen strikt dem >>> OSI-Schichtenmodell. >> >> Das wollte ich auch gerade schreiben. >> Die Aussage des Lehreres ist definitiv falsch. >> >> @TS > > > Blödsinn hoch 10! Der TS hat gesagt: "Er sagt, ALLE Protokolle halten sich " und das ist eben falsch, da TCP/IP nie auf Basis des OSI Schichtenmodells entwickelt wurde. Man hat nur im Nachgang versucht es irgendwie passend zu machen. > Ich finde es äußerst beschämend so über eine Person zu urteilen die sich > hier nicht geäußert hat! Wir können natürlich jetzt nur davon ausgehen, dass der TS wahrheitsgemäß erzählt, was sein Lehrer zu ihm gesagt hat. Alles andere bringt nichts und da der Lehrer hier ein absolute Unbekannte für uns alle ist, sehe ich darin auch kein Problem. > Wenn hier dumme Personen im Forum nachfragt dann hat er selber Probleme > um Verstaendnis. Das hat nichts mit dem Lehrpersonal zu tun. Lehrer wissen auch nicht alles. In den MINT-Fächern auf Lehramtbasis lernen die angehenden Lehramtsstudenten nur einen Bruchteil von dem, was echte MINT-ler in ihrem Studium gelernt haben. Die Lehrer finden somit ihre Meister, sobald sie auf echte MINT-ler stoßen. Glück haben die Schüler, die echte Mint-ler als Lehrer bekommen, die den Stoff ihres unterrichtees Schulfach nicht auf Lehramtbasis gelernt haben. So etwas kann bspw. in den Berufsschulen vorkommen. An den allgemeinen Schulen ist es eher die Ausnahme.
Fabian schrieb: > Das mag ja als Entwickler bei Neuentwicklungen hilfreich sein, aber ich > verstehe einfach nicht warum es scheinbar so immens wichtig ist, Es gibt im Ingenieurbereich einige wenige Grundprinzipien um Probleme zu lösen. Ein Prinzip ist "Teile und herrsche." Um ein komplexes Problem handhabbar und lösbar zu machen zerlegt man es in kleine Teilprobleme. Das OSI-Referenzmodell beschreibt eine solche Zerlegung. Dann macht man im Ingenieurbereich immer gerne etwas nach einem vorgegebenen Schema. Wenn etwas funktioniert, dann zieht man das immer wieder so durch. Darin unterscheidet man sich übrigens gewaltig von der Informatik. Die Informatiker wollen immer alles neu machen, reißen mit dem Arsch ab was sie mit den Händen aufgebaut haben und erkennen dabei nicht einmal wenn sie einen Gewinner haben. Gleichzeitig, dass ist das "Referenz" im Namen, bekommst du mit dem OSI-Referenzmodell einen Vergleichsmaßstab. Genau wie ein Meter zum Vergleich von Längen dient, oder ein Liter zum Vergleich von Volumen, dient das OSI-Referenzmodell zum Vergleich von Netzwerktechniken. Das läuft dann beispielsweise so ab: Du musst ein neues Protokoll lernen. Du lernst nicht alles von Anfang an, sondern ziehst Vergleiche zum Referenzmodell. Alle Konzepte die mit dem Referenzmodell halbwegs übereinstimmen musst du nicht neu lernen wenn du das Referenzmodell gelernt hast. Nur das wo das Protokoll nicht auf die Referenz passt musst du Grundsätzliches neu lernen. > Profibus oder andere Busse in diese Schichten zu zerlegen. Laut unserem > Lehrer würde dadurch die Fehlersuche vereinfacht. Wie sage ich das jetzt? Dein Lehrer ist ein bisschen merkwürdig drauf. Ja, in komplizierten Netzwerkprotokollen helfen die Schichten bei der Fehlersuche. So wichtig ist das Modell da aber nicht, weil man auf die Idee schichtweise vorzugehen auch selber kommt. Schön nacheinander systematisch prüfen. Das ist wieder das "Teile und herrsche". Ist das Kabel drin und sind Signale drauf? Gratulation, du hast soeben die physikalische Schicht geprüft. > wie und warum? Die Doku des Busses hilft mir dabei sicher weiter, das > reine Modell doch eher nicht. Unterschätze nicht die Komplexität einiger Protokolle und Schichten. Ethernet Schicht 1 und Schicht 2 sind auf tausenden von Seiten dokumentiert. Mobilfunk dürfte in die Millionen Seiten gehen. Das ließt du nicht von Anfang bis Ende. Da bist du froh, dass du alle Schichten über und unter der Stelle an der du werkeln musst erst einmal als Black-Box betrachten kannst. > Ich sehe einfach keinen Sinn in diesem > Modell. Ehrlich, dann lass es. Es ist ein Werkzeug. Ich wundere mich immer wenn Handwerker sich selber einschränken und sich selber um Werkzeuge berauben, aber das ist deine Entscheidung. Nicht jedes Werkzeug aus der Werkzeugkiste braucht man jeden Tag. Aber wenn es ernst wird ist man ganz froh, dass man unten in der Kiste noch was liegen hat und man weiß wie man damit umgeht.
Zuerst ein "Danke" an alle Schreiber, fast alles hat mir bis hierhin schon mal geholfen! OSI schrieb: > Es kann schon bei der Fehlersuche helfen, wenn man weiß, wie z.B. auf > dem Bus addressiert und arbitriert wird und dass auf der Schicht 2 und 1 > passiert. Denn wenn man ein Problem nur auf der Anwendungsebene (7) mit > den Nutzdaten hat, dann hat das wahrscheinlich nichts mit Ebene 1 und 2 > zu tun. Das meint dein Lehrer wahrscheinlich damit. OK, das leuchtet ein. Nano schrieb: > Alles andere kannst du somit wiederverwenden und das senkt dann auch die > Fehlersuche im Protokoll. Auch das leuchtet ein. Klar, die Schichten sind im optimalsten Fall getrennt und ich kann diese austauschen. Alles super. Aber gerade an diesem Punkt kommt mein Verständnisproblem: Wenn ja nur beschrieben wird, dass es sowas geben muss, dann bringt mir das OSI-Modell ohne Kenntnisse der verwendeten "Normen" in der Form nichts, da die Schnitstellen unbekannt sind. AH OK! Jetzt fiel der Groschen hoffentlich ;D Das eine geht ohne das andere nicht. Wie sollte man auch eine Norm schreiben, wenn nirgendwo festgelegt wurde, wie weit diese Norm geht. Das OSI-Modell legt also einen Grundrahmen fest, der dann von anderen Protokollen/Normen ausgestaltet wird. Diese wiederum halten sich an die vom Modell gesteckten Grenzen. Ich hoffe das stimmt so und macht Sinn? ;) Dazu passt ja: Hannes J. schrieb: > Es gibt im Ingenieurbereich einige wenige Grundprinzipien um Probleme zu > lösen. Ein Prinzip ist "Teile und herrsche." Um ein komplexes Problem > handhabbar und lösbar zu machen zerlegt man es in kleine Teilprobleme. > Das OSI-Referenzmodell beschreibt eine solche Zerlegung. Also abstrakt gesagt: Man kann die Schichten quasi als Black-Box ansehen. Das OSI-Modell sagt nur, das ich eine Black-Box für z.B. Schicht 3 nehmen kann. Das Protokoll der Box sagt mir dann, wie ich sie anspreche und was sie ausgibt. Diese beiden Dinge sind also völlig unabhängig. Am Anfang der Fragestellung war ich noch der Meinung, das OSI-Modell kümmert sich um alles und definiert auch das allgemeine Aussehen der Schnittstellen. OSI schrieb: > Dass sich die allgemein "im Internet" verwendeten Protokolle strikt an > das Modell halten, ist eben sachlich falsch. Das hat mit der Person gar > nichts zu tun. Nano schrieb: > Wir können natürlich jetzt nur davon ausgehen, dass der TS > wahrheitsgemäß erzählt, was sein Lehrer zu ihm gesagt hat. Ja, so war sinngemäß die Aussage unseres Lehrers. Er sagte, das sich ALLE Protokolle die es gab und derzeit gibt, ohne Einschränkungen in das Modell überführen lassen. Egal ob mündliche Sprache, Rauchzeichen oder sonst was, da es immer die Schichten 1, 2 und 7 geben müsse. Auch hat er vor kurzem Informatik studiert. Soviel zu seiner Bildung. Wie gesagt, wir hatten nur 3 Schulstunden mit ihm, sonst hätte ich nochmal nachfragen können. Vielleicht kann ich das nach der Klausur machen, jetzt habe ich ja Verständnis für das Thema. Versteher schrieb: > Wenn hier dumme Personen im Forum nachfragt dann hat er selber Probleme > um Verstaendnis. Das hat nichts mit dem Lehrpersonal zu tun. Meinst du mich mit der dummen Person?
Fabian schrieb: > Am Anfang der Fragestellung war ich noch der Meinung, das OSI-Modell > kümmert sich um alles und definiert auch das allgemeine Aussehen der > Schnittstellen. Ja, das ist eine Fehlannahme. Das OSI-Modell definiert eben keine Schnittstellen zwischen den Schichten. Ganz im Gegenteil. Jede Schicht packt ihre Daten in ein Paket und gibt das ganze Paket an die Nachbarschicht weiter. Die Schicht darunter Packt dieses Paket unverändert und uninterpretiert in ihr eigenes Paket. Je weiter nach unten, desto mehr Kartons werden in (leicht größere) Kartons verpackt. Das Postgeheimnis wird gewahrt.
Ein text wird oft in Einleitung, Hauptteil und Schluss unterteilt. Dann kannst Du jeden Text nehmen, und den danach unterteilen. Irgendwie stimmt das immer. Manchmal fällt ein Teil weg oder geht in den anderen über oder die Einleitung kommt erst am Schluss.... Aber alle halten sich dran und es erleichtert die Analyse des Textes ... Oder alle Wohnungen haben Flur, Schlafzimmer, Küche, Bad, Wohnzimmer, Arbeitsraum und Abstellkammer. Passt immer, selbst wenn es ein einzimmerarpartment ist.
Das OSI-Modell ist für die Fehlersuche nur ein Hilfsmittel um strukturiert die Ursache einzugrenzen. Für den ersten Einstieg reicht es völlig aus wenn man folgendes verinnerlicht: Die Schritte die auf der Senderseite gemacht werden, müssen in umgekehrter Reihenfolge auf der Empfängerseite durchgeführt werden. Das Bild vom 7-Schichten-Modell unter nachfolgendem Link geht mit den senkrechten Pfeilen deutlicher darauf ein: https://www.elektronik-kompendium.de/sites/kom/0301201.htm Wie bereits von pnuebergang geschrieben ist der Zweck von solchen Modellen eine herstellerunabhängige Beschreibung. Dadurch ist es erst möglich das z.B. eine Baugruppe von Alcatel über ein gemeinsam unterstütztes Protokoll auch mit einer Baugruppe von Beckhoff, Honneywell, Siemens, usw. kommunizieren kann. Egal ob die anderen Hersteller zufälligerweise die gleichen Schaltungskomponenten verwenden, die Firmware mit der gleichen Programmiersprache erstellt haben, usw.. In der Praxis kann man natürlich nicht mehr an allen Stellen nachprüfen und man muß hier dem Hersteller vertrauen das er seine Hausaufgaben bei der Entwicklung gemacht hat. Trotzdem gibt es noch genug Punkte die man auf Sender- und Empfängerseite prüfen kann. In einem kleinen Testaufbau führt das aufgrund der Überschaubarkeit schnell zur Annahme das man diesen ganzen Aufwand mit dem Referenzmodell nicht braucht. In einer großen Fabrikhalle wo die Schaltschränke in 20m Entfernung auf einer Schaltschrankbühne stehen ist das eine völlig andere Situation. Beispiel strukturierte Fehlersuche nach OSI Modell : Ich komme mit meinem PC nicht mehr ins Internet
1 | 1) Browser öffnen und Internetseite aufrufen (Aus den Favoriten auswählen damit sich kein Tippfehler einschleicht) -> Fehlermeldung: Seite kann nicht aufgerufen werden |
2 | 2) Kommandozeile öffnen und Router anpingen -> Fehlermeldung: Keine Antwort |
3 | 3) Auf der Kommandozeile mit ipconfig prüfen ob die Netzwerkkarte eine IP-Adresse hat (sofern DHCP verwendet wird) und wie der Medienstatus lautet -> Meldung: Medium getrennt |
4 | 4) Am PC kontrollieren ob die Link-LED der Netzwerkkarte leuchtet -> Ergebnis: LED ist aus |
5 | 5) Netzwerkkabel am PC aus- und korrekt wieder einstecken -> Ergebnis: LED bleibt aus |
6 | 6) Netzwerkkabel vom PC zum Router verfolgen -> Ergebnis: Kabel ist unterbrochen (Bissspuren einer Katze ;-)) |
7 | 7) Netzwerkkabel austauschen (Ab jetzt in umgekehrter Reihenfolge zurück) |
8 | 8) Am PC kontrollieren ob die Link-LED der Netzwerkkarte leuchtet -> Ergebnis: LED leuchtet |
9 | 9) Auf der Kommandozeile mit ipconfig prüfen ob die Netzwerkkarte eine IP-Adresse hat und wie der Medienstatus lautet -> Meldung: IP-Adresse wird angezeigt |
10 | 10) Seite im Browser aktualisieren -> Seite wird aufgebaut |
Beispiel unstrukturierte Fehlersuche (nicht ganz ernstzunehmen)
1 | 1) Browser öffnen und Internetseite aufrufen (Per Hand eingeben und Tippfehler nicht bemerkt) -> Fehlermeldung: Seite kann nicht aufgerufen werden |
2 | 2) Tippfehler bemerkt und korrigiert -> Fehlermeldung: Seite kann nicht aufgerufen werden |
3 | 3) Alle Programme schließen und PC neustarten |
4 | 4) Browser öffnen und Internetseite aufrufen (Aus den Favoriten auswählen damit sich kein Tippfehler einschleicht) -> Fehlermeldung: Seite kann nicht aufgerufen werden |
5 | 5) Router neustarten (Netzteil aus- und wiedereinstecken) |
6 | 6) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden |
7 | 7) Treiber für Netzwerkkarte deinstallieren, Rechner neustarten und Treiber wieder installieren |
8 | 8) Browser öffnen und Internetseite aufrufen (Wieder aus den Favoriten auswählen) -> Fehlermeldung: Seite kann nicht aufgerufen werden |
9 | 9) Netzwerkkabel am PC aus- und korrekt wieder einstecken |
10 | 10) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden |
11 | 11) Netzwerkkabel am Router aus- und korrekt wieder einstecken |
12 | 12) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden |
13 | 13) Router nochmal neustarten (Netzteil aus- und wiedereinstecken) |
14 | 14) Seite im Browser aktualisieren -> Fehlermeldung: Seite kann nicht aufgerufen werden |
15 | . |
16 | . |
17 | . |
18 | . |
19 | XX) Zufällig das unterbrochene Kabel sehen |
Timo R. schrieb: > Das OSI-Modell ist für die Fehlersuche nur ein Hilfsmittel um > strukturiert die Ursache einzugrenzen. Wenn den Jugendlichen von veralteten Lehrern (Produktion vor 1995) nur das OSI-Modell (mit 7 Schichten) und nicht das TCP/IP-Modell (4 Schichten) beigebracht wird, dann sind die Folgen aus >The OSI protocol suite that was specified as part of the OSI project was considered by many as too complicated and inefficient, and to a large extent unimplementable https://en.wikipedia.org/wiki/OSI_model#Comparison_with_TCP/IP_model in sogenannten 'strukturierten' Fehlersuchen, die unstrukturiert 10 Punkte raten müssen, nachlesbar. Sinnvoll wäre es die Jugendlichen darüber aufzuklären, dass selbst Deutschland Mitte der 1990er die Hoffnung auf ein ITU-Netz nach OSI-Modell als Alternative zum Internet aufgegeben hat und üblicherweise Technik nach dem TCP-IP-Modell verwendet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.