26
Warum ist diese Antwort falsch?
Hallo,
ich übe gerade für den CCNA und bin bei einer Frage bei der ich einfach nicht weiterkomme.
Bei dem Bild im Anhang wird als Lösung beschrieben, dass wenn ein Client ein Paket in ein anderes Subnetz sendet, der Client einen ARP-Eintrag mit der IP der Station im anderen Subnetz und der MAC-Adresse des Gateways erstellt.
Ich verstehe den Sinn nicht, der PC/die Station weiß ja sowieso durch die IP/SM bereits dass diese Station in einem anderen Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Ich habe das ganze in GNS3 nachgebaut, und konnte keine ARP-Einträge ins andere Subnetz auf den VPCs sehen.
Ist das einfach ein Fehler eine falsche Lösung?
Danke für die Antwort!
ich übe gerade für den CCNA und bin bei einer Frage bei der ich einfach nicht weiterkomme.
Bei dem Bild im Anhang wird als Lösung beschrieben, dass wenn ein Client ein Paket in ein anderes Subnetz sendet, der Client einen ARP-Eintrag mit der IP der Station im anderen Subnetz und der MAC-Adresse des Gateways erstellt.
Ich verstehe den Sinn nicht, der PC/die Station weiß ja sowieso durch die IP/SM bereits dass diese Station in einem anderen Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Ich habe das ganze in GNS3 nachgebaut, und konnte keine ARP-Einträge ins andere Subnetz auf den VPCs sehen.
Ist das einfach ein Fehler eine falsche Lösung?
Danke für die Antwort!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 307364
Url: https://administrator.de/contentid/307364
Printed on: April 24, 2024 at 18:04 o'clock
26 Comments
Latest comment
Hi,
nein, das ist korrekt so. Der ARP-Cache ist doch dafür gedacht, dass der Sender nicht jedesmal ins Netz schreien muss, wer denn diese IP-Adresse hat, damit er weiß, an welche physische Adresse er das Paket adressieren muss. Wenn der Empfänger in einem anderen Subnetz ist und er schon mal erfolgreich ein Route dorthin über einen Router ermittelt hat, dann merkt er sich die MAC des Roters zu dieser IP damit er beim nächsten Paket dieses gleich an diese MAC senden kann ohne vorher wieder zu berechnen, dass das Ziel in einem anderen Subnetz ist und welche MAC der zuständige Router hat.
Einfach ausgedrückt.
E.
nein, das ist korrekt so. Der ARP-Cache ist doch dafür gedacht, dass der Sender nicht jedesmal ins Netz schreien muss, wer denn diese IP-Adresse hat, damit er weiß, an welche physische Adresse er das Paket adressieren muss. Wenn der Empfänger in einem anderen Subnetz ist und er schon mal erfolgreich ein Route dorthin über einen Router ermittelt hat, dann merkt er sich die MAC des Roters zu dieser IP damit er beim nächsten Paket dieses gleich an diese MAC senden kann ohne vorher wieder zu berechnen, dass das Ziel in einem anderen Subnetz ist und welche MAC der zuständige Router hat.
Einfach ausgedrückt.
E.
Hallo,
lies dir nochmal die Kapitel bez. Ethernet-Frames sowie des OSI-Modells durch.
MAC- und IP-Adressierung wird ja in verschiedenen Schichten verarbeitet und die verschiedenen Pakete ineinander gekapselt. Für den CCNA musst du wissen, warum und welche Informationen von welchen Systemen verabeitet werden.
Für deine Frage: Switches arbeiten auf Layer2, d.h. sie verabeiten Ethernet-Frames. Welche Information muss dein Client also mitgeben, damit der Switch weiß, dass er es zum Router schicken soll?
Gruß
lies dir nochmal die Kapitel bez. Ethernet-Frames sowie des OSI-Modells durch.
MAC- und IP-Adressierung wird ja in verschiedenen Schichten verarbeitet und die verschiedenen Pakete ineinander gekapselt. Für den CCNA musst du wissen, warum und welche Informationen von welchen Systemen verabeitet werden.
Für deine Frage: Switches arbeiten auf Layer2, d.h. sie verabeiten Ethernet-Frames. Welche Information muss dein Client also mitgeben, damit der Switch weiß, dass er es zum Router schicken soll?
Gruß
Du hast meine Frage nicht verstanden.
Es ist mir klar dass der Switch die MAC des Default-Gateways als Destination braucht. Wenn ein Rechner jedoch an eine Adresse außerhalb seines Subnetztes schickt weiß der PC ja sowieso das er ans GW schicken muss. Die Frage war halt, warum der PC ZUSÄTZLICH noch einen ARP-Eintrag mit der IP im fremden Subnetz und der MAC seines GW erstellt.
Es ist mir klar dass der Switch die MAC des Default-Gateways als Destination braucht. Wenn ein Rechner jedoch an eine Adresse außerhalb seines Subnetztes schickt weiß der PC ja sowieso das er ans GW schicken muss. Die Frage war halt, warum der PC ZUSÄTZLICH noch einen ARP-Eintrag mit der IP im fremden Subnetz und der MAC seines GW erstellt.
Hallo,
ein IP-Paket für ein anderes Subnetz wird nur dann an das Standard-Gateway geschickt, wenn kein anderer Router im gleichen Subnetz wie der Client sich für das Paket zuständig fühlt. Dh., das kein anderer Router eine Route zum gewünschten Ziel-Subnetz kennt. Vereinfacht: Nur Pakete in unbekannte Subnetze werden an das Standard-Gateway geschickt. Und zwar solange, bis ein Router das Ziel-Subnetz kennt oder die TTL abgelaufen ist. Kennt ein Router das Ziel-Subnetz (aus seiner Routing-Tabelle), meldet er sich beim verschickenden Client und dieser schickt das Paket an den zuständigen Router (und nicht an das Standard-GW). Dazu muß er natürlich dessen MAC-Adresse ermitteln/kennen.
Jürgen
ein IP-Paket für ein anderes Subnetz wird nur dann an das Standard-Gateway geschickt, wenn kein anderer Router im gleichen Subnetz wie der Client sich für das Paket zuständig fühlt. Dh., das kein anderer Router eine Route zum gewünschten Ziel-Subnetz kennt. Vereinfacht: Nur Pakete in unbekannte Subnetze werden an das Standard-Gateway geschickt. Und zwar solange, bis ein Router das Ziel-Subnetz kennt oder die TTL abgelaufen ist. Kennt ein Router das Ziel-Subnetz (aus seiner Routing-Tabelle), meldet er sich beim verschickenden Client und dieser schickt das Paket an den zuständigen Router (und nicht an das Standard-GW). Dazu muß er natürlich dessen MAC-Adresse ermitteln/kennen.
Jürgen
Moin,
ich seh das genauso wie du! Richtig sein müsste Antwort D.
Der Client hat nur den ARP Eintrag des Routers, da er alle Packete außerhalb seines Subnetzes sowieso an diesen sendet.
VG
Val
ich seh das genauso wie du! Richtig sein müsste Antwort D.
Der Client hat nur den ARP Eintrag des Routers, da er alle Packete außerhalb seines Subnetzes sowieso an diesen sendet.
Einfach ausgedrückt.
E.
E dürfte komplett falsch sein! Die Mac des Clients und IP des Switches? Niemals!E.
Kennt ein Router das Ziel-Subnetz (aus seiner Routing-Tabelle), meldet er sich beim verschickenden Client und dieser schickt das Paket an den zuständigen Router (und nicht an das Standard-GW). Dazu muß er natürlich dessen MAC-Adresse ermitteln/kennen.
Bitte was? Der Client sendet in dem obigen Beispiel immer an sein GW und der Router welcher dann die benötigten Routen in das andere Netz hat und die Pakete weiterleitet. Der Router sagt dem Client hier garnichts.VG
Val
Hallo,
danke für die Antwort, genau das was du beschreibst habe ich ja auch in GNS3 probiert und auf den VPCs (Virtuelle PCs) waren auch keine ARP-Einträge in andere Subnetze) Wollte jetzt nur sicher gehen.
danke für die Antwort, genau das was du beschreibst habe ich ja auch in GNS3 probiert und auf den VPCs (Virtuelle PCs) waren auch keine ARP-Einträge in andere Subnetze) Wollte jetzt nur sicher gehen.
Hallo @119944,
es gibt in einem Subnetz für das Versenden von IP-Paketen durch einen Client , die nicht im eigenen Subnetz bleiben, immer 2 Möglichkeiten:
1. im eigenen Subnetz befindet sich ein Router, der das Ziel-Subnetz kennt (steht in seiner Routingtabelle). Dann schickt der Client das Paket direkt an diesen Router, der es dann entsprechend seiner Routingtabelle weiterleitet.
2. im Subnetz befindet sich KEIN Router, der das Ziel-Subnetz kennt. In diesem Fall schickt der Client das Paket an sein Standard-GW, das er ja per Konfiguration kennt. Dieses Standard-GW schickt dann das Paket seinerseits an sein Standard-GW. Das wird so lange fortgesetzt, bis ein Router das Ziel-Subnetz kennt und dann das Paket entsprechend seiner Routingtabelle weiterleiten kann.
Im konkreten Fall sind beide Router, also der Router, der in seiner Routingtabelle das Ziel-Subnetz enthält und das Standard-GW, das im Client konfiguriert ist, das selbe Gerät.
Trotzdem muß man die Verarbeitung des IP-Paketes entsprechend unterscheiden. Es soll ja durchaus Sub-Netze geben, in denen mehr als ein Router vorhanden ist. Und auch hier hat der Client nur ein Standard-GW.
Und im Detail: Wenn der Client ein IP-Paket verschicken will, schickt er eine ARP-Anfrage (Ziel-IP ist Broadcast) in sein Subnetz. Befindet sich das Ziel in eigenen Subnetz, schickt die Station mit dieser IP eine ARP-Antwort mit der eigenen MAC-Adresse an den fragenden Client. Diese nimmt diese Info in seine ARP-Tabelle auf und schick das Nutz-Paket an die ihm nun bekannte MAC-Adresse.
Wenn sich das Ziel nicht im eigenem Sub-Netz befindet, antwortet auf die Broadcast ARP-Anfrage der oder die Router, die das Ziel-Subnetz in ihrer Routingtabelle führen mit einer ARP-Antwort, die die MAC-Adresse ihres Router-Interfaces enthält. Entsprechend dem Routing-Algorythmus schickt der Client das Nutz-Paket nun an die MAC-Adresse des Routers, der den "besten" Weg zum Ziel-Subnetz kennt. Im ARP-Cache des Clients wird diese MAC-Adresse eingetragen.
Antwortet niemand auf die Broadcast-ARP-Anfrage des Clients, weil "niemand sich angesprochen fühlt", schickt der Client das Nutz-Paket an das auf ihm konfigurierte Standard-GW. Wenn der Client die zu dieser IP gehörende MAC-Adresse noch nicht "kennt", muß er sie vorher durch eine ARP-Abfrage in Erfahrung bringen. Das Standard-GW muß dann zusehen, wie es das IP-Paket nun wieder los wird --> die ganze Hudelei geht wieder von vorne los. Diesmal aber vom Standard-GW durchgeführt.
In sofern stimmt die Aussage:
so nicht.
Der "Denkfehler" von maxmax liegt in diesem Satz:
Der Host A "weiß" ja nicht, wieviele Router sich in seinem Subnetz befinden und ob einer dieser Router vielleicht das Ziel-Subnetz in seiner Routingtabelle führt. Dashalb muß er erstmal fragen, ob irgend ein Host (Router) sich für das Ziel-Subnetz "zuständig fühlt" (--> ARP-Anfrage als Broadcast mit der Ziel-IP). Erst wenn auf diese ARP-Anfrage keine Antwort erfolgt, schickt Host A das Paket an sein Standard-GW. Hier "kennt" aber der Router 1 das Ziel-Subnetz und antwortet auf die Broadcast-ARP-Anfrage von Host A mit seiner MAC-Adresse. Und diese trägt Host A nun in seine ARP-Tabelle ein.
Der Host A "weiß" zwar an hand von IP und SM, dass das Ziel nicht im eigenen Subnetz ist. Er "weiß" aber (noch) nicht, welcher Router für das Weiterleiten zuständig ist. Das hier nur ein Router sich im Subnetz befindet und damit Standard-GW und der zu benutzender Router identisch sind, muß ja nicht immer so sein. Der Routing-Algorythmus muß aber unter allen Konstellationen funktionieren.
Jürgen
es gibt in einem Subnetz für das Versenden von IP-Paketen durch einen Client , die nicht im eigenen Subnetz bleiben, immer 2 Möglichkeiten:
1. im eigenen Subnetz befindet sich ein Router, der das Ziel-Subnetz kennt (steht in seiner Routingtabelle). Dann schickt der Client das Paket direkt an diesen Router, der es dann entsprechend seiner Routingtabelle weiterleitet.
2. im Subnetz befindet sich KEIN Router, der das Ziel-Subnetz kennt. In diesem Fall schickt der Client das Paket an sein Standard-GW, das er ja per Konfiguration kennt. Dieses Standard-GW schickt dann das Paket seinerseits an sein Standard-GW. Das wird so lange fortgesetzt, bis ein Router das Ziel-Subnetz kennt und dann das Paket entsprechend seiner Routingtabelle weiterleiten kann.
Im konkreten Fall sind beide Router, also der Router, der in seiner Routingtabelle das Ziel-Subnetz enthält und das Standard-GW, das im Client konfiguriert ist, das selbe Gerät.
Trotzdem muß man die Verarbeitung des IP-Paketes entsprechend unterscheiden. Es soll ja durchaus Sub-Netze geben, in denen mehr als ein Router vorhanden ist. Und auch hier hat der Client nur ein Standard-GW.
Und im Detail: Wenn der Client ein IP-Paket verschicken will, schickt er eine ARP-Anfrage (Ziel-IP ist Broadcast) in sein Subnetz. Befindet sich das Ziel in eigenen Subnetz, schickt die Station mit dieser IP eine ARP-Antwort mit der eigenen MAC-Adresse an den fragenden Client. Diese nimmt diese Info in seine ARP-Tabelle auf und schick das Nutz-Paket an die ihm nun bekannte MAC-Adresse.
Wenn sich das Ziel nicht im eigenem Sub-Netz befindet, antwortet auf die Broadcast ARP-Anfrage der oder die Router, die das Ziel-Subnetz in ihrer Routingtabelle führen mit einer ARP-Antwort, die die MAC-Adresse ihres Router-Interfaces enthält. Entsprechend dem Routing-Algorythmus schickt der Client das Nutz-Paket nun an die MAC-Adresse des Routers, der den "besten" Weg zum Ziel-Subnetz kennt. Im ARP-Cache des Clients wird diese MAC-Adresse eingetragen.
Antwortet niemand auf die Broadcast-ARP-Anfrage des Clients, weil "niemand sich angesprochen fühlt", schickt der Client das Nutz-Paket an das auf ihm konfigurierte Standard-GW. Wenn der Client die zu dieser IP gehörende MAC-Adresse noch nicht "kennt", muß er sie vorher durch eine ARP-Abfrage in Erfahrung bringen. Das Standard-GW muß dann zusehen, wie es das IP-Paket nun wieder los wird --> die ganze Hudelei geht wieder von vorne los. Diesmal aber vom Standard-GW durchgeführt.
In sofern stimmt die Aussage:
Der Router sagt dem Client hier garnichts.
so nicht.
Der "Denkfehler" von maxmax liegt in diesem Satz:
Ich verstehe den Sinn nicht, der PC/die Station weiß ja sowieso durch die IP/SM bereits dass diese Station in einem anderen
Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Der Host A "weiß" ja nicht, wieviele Router sich in seinem Subnetz befinden und ob einer dieser Router vielleicht das Ziel-Subnetz in seiner Routingtabelle führt. Dashalb muß er erstmal fragen, ob irgend ein Host (Router) sich für das Ziel-Subnetz "zuständig fühlt" (--> ARP-Anfrage als Broadcast mit der Ziel-IP). Erst wenn auf diese ARP-Anfrage keine Antwort erfolgt, schickt Host A das Paket an sein Standard-GW. Hier "kennt" aber der Router 1 das Ziel-Subnetz und antwortet auf die Broadcast-ARP-Anfrage von Host A mit seiner MAC-Adresse. Und diese trägt Host A nun in seine ARP-Tabelle ein.
Der Host A "weiß" zwar an hand von IP und SM, dass das Ziel nicht im eigenen Subnetz ist. Er "weiß" aber (noch) nicht, welcher Router für das Weiterleiten zuständig ist. Das hier nur ein Router sich im Subnetz befindet und damit Standard-GW und der zu benutzender Router identisch sind, muß ja nicht immer so sein. Der Routing-Algorythmus muß aber unter allen Konstellationen funktionieren.
Jürgen
@chiefteddy
Sorry, aber das stimmt so nicht ganz.
Ein TCP/IP-Client (kein Router) fragt nicht einfach so ins Netzwerk "Hey, wer kennt das Netzwerk 0815?". Entweder hat er ein gezielte Route für dieses Netz konfiguriert oder eine Default Route (0.0.0.0, "Default Gateway") oder nicht.
Hat er keine Route und auch kein Default Gateway und die Ziel-IP befindet sich rein mathematisch nicht in seinem Subnetz, dann meldet er sofort "nicht erreichbar" ohne auch nur den Versuch zu unternehmen, diesen zu erreichen.
Hat er eine gezielte Route für die Ziel-IP, dann verwendet er nur diese. Wenn es darüber nicht geht, dann ist schon wieder Ende.
Hat er mehrere gezielte Routen für die Ziel-IP, dann versucht er diese der Reihe gemäß ihren Wichtungen (Kosten).
Nur wenn er keine gezielte Route hat aber ein Default Gateway, dann versucht er es über letzteres.
@maxmax
Hier mal ein Auzug von meinem Client: s.u.
Mein Client hat die 192.168.249.245. Sein Default GW ist die 192.168.249.241.
Für die Ziele 192.168.172.254 und 192.168.176.1 (beide in anderen Netzen) hat er dieselbe MAC im Cache, wie für das Default GW, nämlich dessen MAC: a8-9d-21-86-c4-e0.
Sorry, aber das stimmt so nicht ganz.
Ein TCP/IP-Client (kein Router) fragt nicht einfach so ins Netzwerk "Hey, wer kennt das Netzwerk 0815?". Entweder hat er ein gezielte Route für dieses Netz konfiguriert oder eine Default Route (0.0.0.0, "Default Gateway") oder nicht.
Hat er keine Route und auch kein Default Gateway und die Ziel-IP befindet sich rein mathematisch nicht in seinem Subnetz, dann meldet er sofort "nicht erreichbar" ohne auch nur den Versuch zu unternehmen, diesen zu erreichen.
Hat er eine gezielte Route für die Ziel-IP, dann verwendet er nur diese. Wenn es darüber nicht geht, dann ist schon wieder Ende.
Hat er mehrere gezielte Routen für die Ziel-IP, dann versucht er diese der Reihe gemäß ihren Wichtungen (Kosten).
Nur wenn er keine gezielte Route hat aber ein Default Gateway, dann versucht er es über letzteres.
@maxmax
Hier mal ein Auzug von meinem Client: s.u.
Mein Client hat die 192.168.249.245. Sein Default GW ist die 192.168.249.241.
Für die Ziele 192.168.172.254 und 192.168.176.1 (beide in anderen Netzen) hat er dieselbe MAC im Cache, wie für das Default GW, nämlich dessen MAC: a8-9d-21-86-c4-e0.
Schnittstelle: 192.168.249.245 --- 0x3
Internetadresse Physische Adresse Typ
192.168.172.254 a8-9d-21-86-c4-e0 dynamisch
192.168.176.1 a8-9d-21-86-c4-e0 dynamisch
192.168.249.241 a8-9d-21-86-c4-e0 dynamisch
192.168.249.242 00-21-a0-85-a2-cb dynamisch
192.168.249.246 f4-ce-46-fc-49-e6 dynamisch
192.168.249.255 ff-ff-ff-ff-ff-ff statisch
224.0.0.22 01-00-5e-00-00-16 statisch
224.0.0.251 01-00-5e-00-00-fb statisch
224.0.0.252 01-00-5e-00-00-fc statisch
225.1.2.3 01-00-5e-01-02-03 statisch
239.255.255.250 01-00-5e-7f-ff-fa statisch
239.255.255.253 01-00-5e-7f-ff-fd statisch
255.255.255.255 ff-ff-ff-ff-ff-ff statisch
ipconfig
IPv4-Adresse . . . . . . . . . . : 192.168.249.245
Subnetzmaske . . . . . . . . . . : 255.255.255.240
Standardgateway . . . . . . . . . : 192.168.249.241Wenn sich das Ziel nicht im eigenem Sub-Netz befindet, antwortet auf die Broadcast ARP-Anfrage der oder die Router, die das Ziel-Subnetz in ihrer Routingtabelle führen mit einer ARP-Antwort, die die MAC-Adresse ihres Router-Interfaces enthält. Entsprechend dem Routing-Algorythmus schickt der Client das Nutz-Paket nun an die MAC-Adresse des Routers, der den "besten" Weg zum Ziel-Subnetz kennt. Im ARP-Cache des Clients wird diese MAC-Adresse eingetragen.
Wenn dem so wäre, würde das doch bedeuten, dass man dem Client gar kein Default Gateway eintragen müsste. Er kann ja einfach ins Netz fragen und irgendein Router meldet sich dann schon. Dem ist aber nicht so.
Hallo @emeriks,
nehmen wir mal an, Du sitzt vor Deinem PC und Du willst einfach mal so ein Ping auf die Adresse 223.3.74.151 absetzen. Dein PC hat die Adresse 223.4.133.12 mit der SM 255.255.255.0 und dem Standard-GW 223.4.133.254.
Woher soll denn Dein Router auch nur ansatzweise wissen, das es das Subnetz 223.3.74.0 gibt und wie man da hin kommt. Da dieses Subnetz Deinem Router nicht bekannt ist und auch nicht Deinem PC, müßte ja nach Deiner Meinung sofort "nicht erreichbar" erscheinen. Du wirst mir sicher zustimmen, dass das nicht geschieht.
Und ein Router führt eine Routingtabelle, nicht ein Host (Client-PC)!
Und selbst wenn, wie sollte denn Dein PC nach dem Einschalten alle im Internet vorhandenen Subnetze kennen???
Jürgen
nehmen wir mal an, Du sitzt vor Deinem PC und Du willst einfach mal so ein Ping auf die Adresse 223.3.74.151 absetzen. Dein PC hat die Adresse 223.4.133.12 mit der SM 255.255.255.0 und dem Standard-GW 223.4.133.254.
Woher soll denn Dein Router auch nur ansatzweise wissen, das es das Subnetz 223.3.74.0 gibt und wie man da hin kommt. Da dieses Subnetz Deinem Router nicht bekannt ist und auch nicht Deinem PC, müßte ja nach Deiner Meinung sofort "nicht erreichbar" erscheinen. Du wirst mir sicher zustimmen, dass das nicht geschieht.
Und ein Router führt eine Routingtabelle, nicht ein Host (Client-PC)!
Und selbst wenn, wie sollte denn Dein PC nach dem Einschalten alle im Internet vorhandenen Subnetze kennen???
Jürgen
Wenn dem so wäre, würde das doch bedeuten, dass man dem Client gar kein Default Gateway eintragen müsste. Er kann ja einfach
ins Netz fragen und irgendein Router meldet sich dann schon. Dem ist aber nicht so.
ins Netz fragen und irgendein Router meldet sich dann schon. Dem ist aber nicht so.
Hallo @emeriks,
Du übersiehst dabei, das die ARP-Anfragen über Broadcast gehen und Broadcast wird ja bekanntlich nicht geroutet! Wenn also eine ARP-Anfrage nicht von einem Host oder einem Router im gleichen Subnetz beantwortet wird, schickt der anfragende Host die Pakete an das auf ihm konfigurierte Standard-GW. Aber auch nur dann!
Wenn der Host auf seine Anfrage eine Antwort bekommt, kennt er ja dann das Ziel (MAC-Adresse) seiner Pakete.
Jürgen
Die Frage des TO:
Fakt ist, ein TCP/IP Host (von mir aus "Client") ohne Route in ein anderes Subnetz (gezielt oder Default GW) kann nur im eigenen Subnetz kommunizieren. Da können soviel Router, welche sich "auskennen", im Subnetz sein, wie sie wollen. Da passiert nichts.
... dass wenn ein Client ein Paket in ein anderes Subnetz sendet, der Client einen ARP-Eintrag mit der IP der Station im anderen Subnetz und der MAC-Adresse des Gateways erstellt.
...
Ich verstehe den Sinn nicht, der PC/die Station weiß ja sowieso durch die IP/SM bereits dass diese Station in einem anderen Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Wir reden also nicht von Routern....
Ich verstehe den Sinn nicht, der PC/die Station weiß ja sowieso durch die IP/SM bereits dass diese Station in einem anderen Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Und ein Router führt eine Routingtabelle, nicht ein Host (Client-PC)!
Jeder TCP/IP-Host führt ein Routing Tabelle. TCP/IP Einmaleins.Woher soll denn Dein Router auch nur ansatzweise wissen, das es das Subnetz 223.3.74.0 gibt und wie man da hin kommt. Da dieses Subnetz Deinem Router nicht bekannt ist und auch nicht Deinem PC, müßte ja nach Deiner Meinung sofort "nicht erreichbar" erscheinen. Du wirst mir sicher zustimmen, dass das nicht geschieht.
Router untereinander können sich abgleichen und die Routen voneinander lernen. Wenn sie dafür konfiguriert sind. Aber auch nur dann. RIP, OSPF usw. sind hier die Stichwörter. Aber Router sind hier nicht das Thema. Es geht um den ARP Cache am Client.Und selbst wenn, wie sollte denn Dein PC nach dem Einschalten alle im Internet vorhandenen Subnetze kennen???
Kennt er nicht. Hat auch niemand behauptet. Aber er kennt meistens jemanden - sein Default Gateway -, der dieses kennt, oder jemanden, der jemanden kennt, der dieses kennt.Fakt ist, ein TCP/IP Host (von mir aus "Client") ohne Route in ein anderes Subnetz (gezielt oder Default GW) kann nur im eigenen Subnetz kommunizieren. Da können soviel Router, welche sich "auskennen", im Subnetz sein, wie sie wollen. Da passiert nichts.
@maxmax
Hier mal ein Auzug von meinem Client: s.u.
Mein Client hat die 192.168.249.245. Sein Default GW ist die 192.168.249.241.
Für die Ziele 192.168.172.254 und 192.168.176.1 (beide in anderen Netzen) hat er dieselbe MAC im Cache, wie für das Default GW, nämlich dessen MAC: a8-9d-21-86-c4-e0.
Ich hab jetz mal bei mir getestet getestet:Hier mal ein Auzug von meinem Client: s.u.
Mein Client hat die 192.168.249.245. Sein Default GW ist die 192.168.249.241.
Für die Ziele 192.168.172.254 und 192.168.176.1 (beide in anderen Netzen) hat er dieselbe MAC im Cache, wie für das Default GW, nämlich dessen MAC: a8-9d-21-86-c4-e0.
Wenn ich von einem PC-A (10.45.40.29)auf einen PC-B (10.45.60.153) in einem anderen Subnetz pinge und diese beiden durch einen Cisco SG500 L3-Switch getrennt sind, dann habe ich auf PC-A keinen ARP Eintrag für PC-B.
Warum wird es bei dir angezeigt aber bei mir nicht?
VG
Val
Warum wird es bei dir angezeigt aber bei mir nicht?
Gute Frage ... hmJeder TCP/IP-Host führt ein Routing Tabelle. TCP/IP Einmaleins.
Hallo @emeriks,
wenn jeder Host in einem IP-Netz - also jedes "Gerät" mit einer IP-Adresse (zB. PC, Server, Drucker mit Ethernetschnittstelle, managebarer Switch, LAN-to-USB- oder -COM-Server usw) - eine Routingtabelle führt, was unterscheidet diese Hosts denn dann von einem "Router"?
Routing-Tabellen werden von Routern erstellt und verwaltet, weil sie die für ihre "Arbeit" brauchen und von niemanden sonst. Einmaleins des OSI-7-Schichten-Modells (auch wenn TCP/IP nicht voll kompatibel ist).
Router gleichen ihr "Wissen" ( Routing-Tabelle) über das Netzwerk untereinander über sogenannte Routing-Protokolle - RIP, OSPF usw. - ab. Sie teilen dieses "Wissen" aber nicht mit jedem beliebigen Host im Netzwerk. Warum auch, die können damit ja nichts anfangen (routen).
Kennt er nicht. Hat auch niemand behauptet. Aber er kennt meistens jemanden - sein Default Gateway -, der dieses kennt,
oder jemanden, der jemanden kennt, der dieses kennt.
oder jemanden, der jemanden kennt, der dieses kennt.
Das setzt ja voraus, das jeder Router jedes Subnetz im Netz (Internet) kennt. Das ist ja Blödsinn, wie wir wissen. Desshalb wird ja unterschieden, ob es im eigenem Subnetz einen Router gibt, der den Weg zum Ziel-Subnetz kennt --> dann wird das Paket an ihn geschickt. Oder kein Router kennt das Ziel-Subnetz --> dann geht das Paket über das Standard-GW.
Der einzelne Host kennt nur die Struktur des gesamten Netzwerkes insoweit, wie sie sich in seiner ARP-Tabelle wiederspiegelt. Ein Host (solang er kein Router ist) "spricht" kein RIP, OSPF oä.. Damit kann er nicht mit einem Router kommunizieren und dessen Routingtabelle erhalten. Damit hat der Host auch niemals das "Wissen" über die Struktur des Netzes wie sie ein Router hat.
Übrigens: Wieso sollte ausgerechnet das Standard-GW ein völlig unbekanntes Netzwerk kennen?
Aber er kennt meistens jemanden - sein Default Gateway -, der dieses kennt, ......
Wenn das Standard-GW das unbekannte Subnetz "kennt", würden ja auch alle anderen Router dieses unbekannte Subnetz "kennen", da jeder Router seinen "Kollegen" mehr oder weniger regelmäßig über sein "Wissen" über die Strucktur des Netzes informiert (Routingprotokolle RIP, OSPF usw.). Damit wäre jedes "unbekannte" Netz ja in kürzester Zeit ein "bekanntes" Netz. Und jeder Router auf der Welt würde jedes Subnetz auf der Welt kennen.
Genau das passiert ja eben nicht und darum gibt es das Standard-GW, das eben in seiner Funktion als Standard-GW für diese "unbekannten" Subnetze zuständig ist. Ein Standard-GW ist aber zugleich auch ein "normaler" Router mit einer Routingtabelle und arbeitet für die ihm bekannten Subnetze eben als "normaler" Router.
Jürgen
PS: Wenn Du mir Deine Mail-Adresse zukommen läßt, schicke ich Dir gerne ein Kapitel aus einer alten Schulungsunterlage, die die Thematik sehr anschaulich erklärt.
Hab gerade nochmal ein frisches Windows 10 getestet (vorher Windows 8.1) und hier ist ebenfalls kein ARP Eintrag für das andere Subnetz vorhanden.
@119944
Ich stehe gerade voll auf dem Schlauch, kann dass auch bei mir nicht mehr reproduzieren .... ??
Soviel zu meinem Einmaleins
Habe ich da etwa bzgl ARP-Cache Mist erzählt ...?
@chiefteddy
Wir reden garantiert von der gleichen Sache, jeder aber irgendwie anders.
Gib auf einem Windows Rechner einfach mal "route print" ein. Dann zeigt er Dir seine Routing-Tabelle. Diese kann mann auch bearbeiten. Unter Linux natürlich analog.
Das Standard-GW gibt es nicht, weil sich die Router nicht untereinander abgleichen und nicht jeder jedes Netz kennt.
Das Standard-GW ist nichts weiter als die Standard-Route eines Host. Standard-GW ist keine Funktion.
Ich stehe gerade voll auf dem Schlauch, kann dass auch bei mir nicht mehr reproduzieren .... ??
Soviel zu meinem Einmaleins
Habe ich da etwa bzgl ARP-Cache Mist erzählt ...?@chiefteddy
Wir reden garantiert von der gleichen Sache, jeder aber irgendwie anders.
wenn jeder Host in einem IP-Netz - also jedes "Gerät" mit einer IP-Adresse (zB. PC, Server, Drucker mit Ethernetschnittstelle, managebarer Switch, LAN-to-USB- oder -COM-Server usw) - eine Routingtabelle führt, was unterscheidet diese Hosts denn dann von einem "Router"?
Jeder TCP/IP-Router ist ein TCP/IP-Host aber nicht jeder TCP/IP-Host ein Router. "Router sein" ist eine Funktion eines TCP/IP Host.Gib auf einem Windows Rechner einfach mal "route print" ein. Dann zeigt er Dir seine Routing-Tabelle. Diese kann mann auch bearbeiten. Unter Linux natürlich analog.
Router gleichen ihr "Wissen" ( Routing-Tabelle) über das Netzwerk untereinander über sogenannte Routing-Protokolle - RIP, OSPF usw. - ab. Sie teilen dieses "Wissen" aber nicht mit jedem beliebigen Host im Netzwerk. Warum auch, die können damit ja nichts anfangen (routen).
Nichts anderes habe ich doch geschrieben?Das setzt ja voraus, das jeder Router jedes Subnetz im Netz (Internet) kennt.
Nein, wieso denn? Ein Host sendet ein Paket für außerhalb seines Sunbetz an den entsprechenden Router (den, den er für dieses Ziel kennt). Unabhängig davon, ob der Router selbst eine Route zu diesem Ziel hat oder nicht. Der Host weiß das ja nicht. Und wenn Du 1000x ein Ziel pingst, welches außerhalb Deines Subnetz ist, dann wird 1000x der Router angesprochen und meldet 1000x, dass das Ziel nicht erreichbar ist.Desshalb wird ja unterschieden, ob es im eigenem Subnetz einen Router gibt, der den Weg zum Ziel-Subnetz kennt
Router, über welche man ein Paket in ein anderes Netz senden will, müssen immer im eigenen Subnetz sein.Oder kein Router kennt das Ziel-Subnetz --> dann geht das Paket über das Standard-GW.
Richtig, sofern der Host mit einem Default GW konfiguriert ist.Der einzelne Host kennt nur die Struktur des gesamten Netzwerkes insoweit, wie sie sich in seiner ARP-Tabelle wiederspiegelt. Ein Host (solang er kein Router ist) "spricht" kein RIP, OSPF oä.. Damit kann er nicht mit einem Router kommunizieren und dessen Routingtabelle erhalten. Damit hat der Host auch niemals das "Wissen" über die Struktur des Netzes wie sie ein Router hat.
Das hat hier doch niemand gesagt/geschrieben?Übrigens: Wieso sollte ausgerechnet das Standard-GW ein völlig unbekanntes Netzwerk kennen?
Keine Ahnung. Wer hat das gesagt oder gefragt?Wenn das Standard-GW das unbekannte Subnetz "kennt", würden ja auch alle anderen Router dieses unbekannte Subnetz "kennen", da jeder Router seinen "Kollegen" mehr oder weniger regelmäßig über sein "Wissen" über die Strucktur des Netzes informiert (Routingprotokolle RIP, OSPF usw.). Damit wäre jedes "unbekannte" Netz ja in kürzester Zeit ein "bekanntes" Netz. Und jeder Router auf der Welt würde jedes Subnetz auf der Welt kennen.
Router können sich über RIP, OSPF uws. austauschen, sofern sie dafür konfiguriert sind. Das ist optional und kein Automatismus. Sie können Partner eingetragen haben, mit welchen sie sich abgleichen können.Genau das passiert ja eben nicht und darum gibt es das Standard-GW, das eben in seiner Funktion als Standard-GW für diese "unbekannten" Subnetze zuständig ist. Ein Standard-GW ist aber zugleich auch ein "normaler" Router mit einer Routingtabelle und arbeitet für die ihm bekannten Subnetze eben als "normaler" Router.
Irgendwie drehst Du Dich gerade im Kreis. Das Standard-GW gibt es nicht, weil sich die Router nicht untereinander abgleichen und nicht jeder jedes Netz kennt.
Das Standard-GW ist nichts weiter als die Standard-Route eines Host. Standard-GW ist keine Funktion.
Hallo @emeriks,
ich kann Dir nur noch einmal anbieten, Dir das Lehrmaterial zukommen zu lassen.
Woher kennt der Host die Route? Wer hat sie ihm mitgeteilt? Wie hat er sie ermittelt?
Frag Dich doch mal, wie nach dem einschalten eines Hosts diese Informationen zu ihm gelangen. Und bitte nicht an RIP, OSPF usw. denken, die sind auf einem Host, der kein Router ist nämlich nicht implementiert!
DU!
Das ist richtig. Wenn die Router aber nicht über ein Routingprotokoll ihr "Wissen" untereinander austauschen, wird viel Effizienz beim Routing verschenkt. Weil ein Host dann eben seine Pakete für ein fremdes Subnetz IMMER an das Standard-GW schicken muß, selbst dann, wenn ein anderer Router in seinem Subnetz ein "besserer" Weg wäre.
Wir sollten hier aber die Diskussion beenden, da wir anscheinend nicht zueinander finden.
Jürgen
ich kann Dir nur noch einmal anbieten, Dir das Lehrmaterial zukommen zu lassen.
Nein, wieso denn? Ein Host sendet ein Paket für außerhalb seines Sunbetz an den entsprechenden Router (den, den er für dieses Ziel kennt).
Woher kennt der Host die Route? Wer hat sie ihm mitgeteilt? Wie hat er sie ermittelt?
Frag Dich doch mal, wie nach dem einschalten eines Hosts diese Informationen zu ihm gelangen. Und bitte nicht an RIP, OSPF usw. denken, die sind auf einem Host, der kein Router ist nämlich nicht implementiert!
> Übrigens: Wieso sollte ausgerechnet das Standard-GW ein völlig unbekanntes Netzwerk kennen?
Keine Ahnung. Wer hat das gesagt oder gefragt?
Keine Ahnung. Wer hat das gesagt oder gefragt?
DU!
Aber er kennt meistens jemanden - sein Default Gateway -, der dieses kennt, oder jemanden, der jemanden kennt, der dieses kennt.
Router können sich über RIP, OSPF uws. austauschen, sofern sie dafür konfiguriert sind. Das ist optional und kein Automatismus.
Sie können Partner eingetragen haben, mit welchen sie sich abgleichen können.
Sie können Partner eingetragen haben, mit welchen sie sich abgleichen können.
Das ist richtig. Wenn die Router aber nicht über ein Routingprotokoll ihr "Wissen" untereinander austauschen, wird viel Effizienz beim Routing verschenkt. Weil ein Host dann eben seine Pakete für ein fremdes Subnetz IMMER an das Standard-GW schicken muß, selbst dann, wenn ein anderer Router in seinem Subnetz ein "besserer" Weg wäre.
Wir sollten hier aber die Diskussion beenden, da wir anscheinend nicht zueinander finden.
Jürgen
Wenn Du meine Antworten komplett aus dem Zusammenhang nimmst und wild durcheinander fegst, dann erklärt das allerdings Deine Antworten.
Trotzdem, immer wieder gerne.
mfg
Emeriks
Wir sollten hier aber die Diskussion beenden, da wir anscheinend nicht zueinander finden.
ditoTrotzdem, immer wieder gerne.
mfg
Emeriks
Moin,
Was treibt ihr nur wieder?
Die Sache ist doch recht simpel. D ist richtig. (Ich habe es sicherheitshalber auch mal auf diversen OS probiert ^^)
Jetzt zum Routing. Jedes Device in einem IP Netz muss Routen können. Routen bedeutet hier, die nächste Zieladresse des Frames für ein IP-Paket finden.
Jetzt wird es umständlich. Zunächst wird geschaut, welche Route mit der höchsten Genauigkeit auf die Zieladresse des IP-Pakets zutrifft.
Für das Ergebnis gibt es 2 Möglichkeiten:
Wenn sich die IP *NICHT* in einem direkt anliegenden Netz befindet wird die IP des entsprechenden Gateways ermittelt. (Dies ist meist das Standardgateway)
Nun wird per ARP angefragt welche MAC-Adresse die Ziel-IP(wenn in anliegendem Netz) oder die Gateway-IP(wenn außerhalb) hat. Dorthin wird nun der Frame mit dem IP Paket geschickt.
Fertig. Das geht solange, bis das Paket sein Ziel erreicht.
Der ARP-Cache wird hier genutzt um die Anzahl der Anfragen die wirklich ins Netzwerk hinaus gehen zu minimieren. Hierfür wird die Zieladresse des Frames gechached also das angefragte Ziel, nach dem Routingvorgang. Deswegen ist eigentlich nur Antwort D sinnvoll.
ABER
Aus Sicht eines findigen Programmierers ergibt auch Lösung A Sinn. Referenziere ich direkt die Ziel-IP ARP Cache solange sich nichts an der Routingtabelle ändert, da ich mir so den ganzen Routingzusammenhang spare. Da die Wahrscheinlichkeit, dass sich die Routingtablle ständig ändert, sehr gering ist, würde dies die Verarbeitung der IP-Pakete stark beschleunigen, da ich schneller referenzieren kann. Aber wie ich selbst festgestellt habe, ist dies in den aktuellen gängigen Implementierungen wohl nicht der Fall.
Ich weiß nicht genau wie sich Cisco hier verhält. Aber möglich wäre das schon, gerade in größeren Routern ist es halt sinnvoll, da ich mir eine Menge rechenaufwand spare und die Pakete dann trotz Layer3 Routing auf Layer2 verarbeiten kann. Ist halt wieder die Frage, was teurer ist: Rechenzeit oder Speicher ;)
Gruß
Chris
Was treibt ihr nur wieder?
Die Sache ist doch recht simpel. D ist richtig. (Ich habe es sicherheitshalber auch mal auf diversen OS probiert ^^)
Jetzt zum Routing. Jedes Device in einem IP Netz muss Routen können. Routen bedeutet hier, die nächste Zieladresse des Frames für ein IP-Paket finden.
Jetzt wird es umständlich. Zunächst wird geschaut, welche Route mit der höchsten Genauigkeit auf die Zieladresse des IP-Pakets zutrifft.
Für das Ergebnis gibt es 2 Möglichkeiten:
Wenn sich die IP *NICHT* in einem direkt anliegenden Netz befindet wird die IP des entsprechenden Gateways ermittelt. (Dies ist meist das Standardgateway)
Nun wird per ARP angefragt welche MAC-Adresse die Ziel-IP(wenn in anliegendem Netz) oder die Gateway-IP(wenn außerhalb) hat. Dorthin wird nun der Frame mit dem IP Paket geschickt.
Fertig. Das geht solange, bis das Paket sein Ziel erreicht.
Der ARP-Cache wird hier genutzt um die Anzahl der Anfragen die wirklich ins Netzwerk hinaus gehen zu minimieren. Hierfür wird die Zieladresse des Frames gechached also das angefragte Ziel, nach dem Routingvorgang. Deswegen ist eigentlich nur Antwort D sinnvoll.
ABER
Aus Sicht eines findigen Programmierers ergibt auch Lösung A Sinn. Referenziere ich direkt die Ziel-IP ARP Cache solange sich nichts an der Routingtabelle ändert, da ich mir so den ganzen Routingzusammenhang spare. Da die Wahrscheinlichkeit, dass sich die Routingtablle ständig ändert, sehr gering ist, würde dies die Verarbeitung der IP-Pakete stark beschleunigen, da ich schneller referenzieren kann. Aber wie ich selbst festgestellt habe, ist dies in den aktuellen gängigen Implementierungen wohl nicht der Fall.
Ich weiß nicht genau wie sich Cisco hier verhält. Aber möglich wäre das schon, gerade in größeren Routern ist es halt sinnvoll, da ich mir eine Menge rechenaufwand spare und die Pakete dann trotz Layer3 Routing auf Layer2 verarbeiten kann. Ist halt wieder die Frage, was teurer ist: Rechenzeit oder Speicher ;)
Gruß
Chris
Jedes Device in einem IP Netz muss Routen können.
Hallo @Sheogorath,
das ist Blödsinn! Entschuldige die harte Wortwahl.
Ein Router muß routen können, deshalb heißt er auch Router. Andere Hosts (IP-Geräte), bei denen die Schicht 3 leer ist - also keine Funktion implementiert ist - können nicht routen
https://de.wikipedia.org/wiki/Router
https://de.wikipedia.org/wiki/Routing
Routing ist eine Funktion, die in der Schicht 3 des OSI-Modells angeordnet ist. Routing heißt übersetzt "Weg finden". Dazu sind bestimmte Mechanismen notwendig (zB. Distance-Vector- oder Link-State-Routing); es müssen bestimmte Protokolle (RIP, OSPF usw.) implementiert sein usw.
Wenn die nicht da sind, kann das Gerät nicht routen.
Routing ist bei einem Windows-Server bei einer Standard-Installation gar nicht mitinstalliert und muß erst zusätzlich als Funktion installiert werden. Erst dann kann er routen, egal wieviele NICs installiert sind. Ich kann zwar aus den anliegenden Subnetzen jeweils den Server erreichen. Aber der Server leitet Datenpakete von einem Subnetz nicht in das andere weiter. Die Hosts in den jeweiligen Subnetzen "wissen" auch nichts von den Hosts in jeweils anderen Subnetz.
Bei Windows-Desktop-BS kann man das gar nicht (mit Ausnahmen: Internetverbindungsfreigabe --> das ist aber kein vollwertiger "Router").
Jürgen
Moin,
leider liegst du falsch.
Denn auch ein Host muss initial "einen Weg finden" also Routen. Ebenso kannst du die Routingtabelle auf einem Host manipulieren. RIP, OSPF und Co sind Protokolle um Routen auszutauschen, nicht um zu routen. Routing passiert im Kernel auf Paketebene.
Aus Netzwerker Sicht, sollte ein Client nicht routen, aber er kann. IMMER! Er leitet nur meist per Default settings keine Pakete von anderen Hosts weiter. Routing findet aber dennoch für die Eigenen Pakete inital statt. Beweis? Kein Problem, machen wir es doch auf Windows:
Nimm Ein Notebook und hänge es mit dem Kabel an einen Switch und connecte es per WLAN mit einem andern Netzwerk. Achte auf getrennte IP Bereiche also Beispielweise
192.168.0.0/24 und 192.168.1.0/24
Gebe nun deinen Interfaces in diesen Beiden Netzen entsprechend feste IPs. Also z.B. 192.168.0.5 und 192.168.1.5
Jetzt hängst du in beide Netze je einen Router der Internet Zugriff bietet (Nehmen wir hier mal die IPs 192.168.0.1 und 192.168.1.1 an) und setzt nur für eines der Interfaces ein Defaultgateway. z.B. das WLAN also zum Beispiel 192.168.1.1. (In unserem Beispiel besitzt das Interface mit der 192.168.0.5 kein Defaultgateway also keine 0.0.0.0/0 Route ;))
Nun mache einen tracert auf 8.8.8.8 Siehe da die Pakete gehen über 192.168.1.1. Nichts neues.
Nun setze eine spezifischere Route (auf deinem Notebook) mit `route add 8.0.0.0 mask 255.0.0.0 192.168.0.1` (muss als Admin ausgeführt werden).
Jetzt führst du erneut den Tracert aus und siehe da: Routing! Die Pakete gehen über 192.168.0.1.
Da man heute in der Regel auf einem Endgerät(Host) N Netzwerkschnittstellen ansprechen kann, auf denen man wiederum IP spricht, ist ein Routing innerhalb des Kernel zwangsweise notwendig. Dass Windows hier teilweise das Forwarding von Paketen beschränkt ist eine ganz andere Sache, die erstmal nichts mit dem eigentlich Routingprozess an sich zu tun hat. Routing ist allein für die Interfacewahl innerhalb des Kernels unabdingbar und notwendig.
Am besten schaust du dir mal den Linux Network Stack an um das zu verstehen ;)
Gruß
Chris
PS: Du kannst das Beispiel auch mit 2 Routern im gleichen Netz durchspielen und einfach für die spezifische Route das nicht Standardgateway angeben. Der Effekt ist der Gleiche.
PS2: Ganz davon abgesehen, muss du Grundsätzlich routen können um überhaupt dein Defaultgateway zu finden. Denn das Defaultgateway ist eine Route auf 0.0.0.0/0, wofür dein Kernel routen können muss ;)
PS3: Und um das ganze Abzurunden: Es braucht keine Serverversion um mit Windows auch forward routing machen zu können ;) https://support.microsoft.com/en-us/kb/315236
Sry, but you failed =P
leider liegst du falsch.
Denn auch ein Host muss initial "einen Weg finden" also Routen. Ebenso kannst du die Routingtabelle auf einem Host manipulieren. RIP, OSPF und Co sind Protokolle um Routen auszutauschen, nicht um zu routen. Routing passiert im Kernel auf Paketebene.
Aus Netzwerker Sicht, sollte ein Client nicht routen, aber er kann. IMMER! Er leitet nur meist per Default settings keine Pakete von anderen Hosts weiter. Routing findet aber dennoch für die Eigenen Pakete inital statt. Beweis? Kein Problem, machen wir es doch auf Windows:
Nimm Ein Notebook und hänge es mit dem Kabel an einen Switch und connecte es per WLAN mit einem andern Netzwerk. Achte auf getrennte IP Bereiche also Beispielweise
192.168.0.0/24 und 192.168.1.0/24
Gebe nun deinen Interfaces in diesen Beiden Netzen entsprechend feste IPs. Also z.B. 192.168.0.5 und 192.168.1.5
Jetzt hängst du in beide Netze je einen Router der Internet Zugriff bietet (Nehmen wir hier mal die IPs 192.168.0.1 und 192.168.1.1 an) und setzt nur für eines der Interfaces ein Defaultgateway. z.B. das WLAN also zum Beispiel 192.168.1.1. (In unserem Beispiel besitzt das Interface mit der 192.168.0.5 kein Defaultgateway also keine 0.0.0.0/0 Route ;))
Nun mache einen tracert auf 8.8.8.8 Siehe da die Pakete gehen über 192.168.1.1. Nichts neues.
Nun setze eine spezifischere Route (auf deinem Notebook) mit `route add 8.0.0.0 mask 255.0.0.0 192.168.0.1` (muss als Admin ausgeführt werden).
Jetzt führst du erneut den Tracert aus und siehe da: Routing! Die Pakete gehen über 192.168.0.1.
Da man heute in der Regel auf einem Endgerät(Host) N Netzwerkschnittstellen ansprechen kann, auf denen man wiederum IP spricht, ist ein Routing innerhalb des Kernel zwangsweise notwendig. Dass Windows hier teilweise das Forwarding von Paketen beschränkt ist eine ganz andere Sache, die erstmal nichts mit dem eigentlich Routingprozess an sich zu tun hat. Routing ist allein für die Interfacewahl innerhalb des Kernels unabdingbar und notwendig.
Am besten schaust du dir mal den Linux Network Stack an um das zu verstehen ;)
Gruß
Chris
PS: Du kannst das Beispiel auch mit 2 Routern im gleichen Netz durchspielen und einfach für die spezifische Route das nicht Standardgateway angeben. Der Effekt ist der Gleiche.
PS2: Ganz davon abgesehen, muss du Grundsätzlich routen können um überhaupt dein Defaultgateway zu finden. Denn das Defaultgateway ist eine Route auf 0.0.0.0/0, wofür dein Kernel routen können muss ;)
PS3: Und um das ganze Abzurunden: Es braucht keine Serverversion um mit Windows auch forward routing machen zu können ;) https://support.microsoft.com/en-us/kb/315236
Sry, but you failed =P
Hallo @Sheogorath,
ich glaube, wir aben ein Verständigungsproblem:
Ich betrachte Routing aus sicht eines Netzwerkes mit vielen Subnetzen, vielen Routern und vielen möglichen Wegen von Quelle zum Ziel. Also das was man im Netzwerk - egal welches Protokoll TCP/IP, SPX/IPX, ATM usw - entsprechend dem OSI-Referenzmodel vorfindet.
Du schaust Dir den PC an und wie dort intern Datenpakete gehändelt werden. Das ist etwas ganz anderes. Und damit haben wir allein schon bei den Begriffen ein Problem!
Routen ist OSI-Referenzmodel eindeutig definiert und hat mit Deiner Interpretation nichts zu tun.
Da der TO ja eine Cisco-Schulung macht, gebe ich Dir Brief und Siegel drauf, dass sich Cisco an die Nomenklatur des OSI-Referenzmodels hält. Und da routet ein Router und nicht irgend ein beliebiger Host mit einer IP-Adresse.
Aber ich will ja gerne noch dazu lernen. Erkläre mir dann doch mal, wie ein billiger L2-Switch mit Management-Interface oder ein Drucker mit LAN-Anschluß "routet". Und komm mir jetzt nicht damit, dass da ja eigentlich immer ein Embedded-Linux drauf läuft.
Und wen Du schon mal dabei bist: Kann ich meinen DrayTek-Router eigendlich einsparen und statt dessen meinen Tintenstrahldrucker mit LAN- und WLAN-Anschluß als Router einsetzen?
Jürgen
ich glaube, wir aben ein Verständigungsproblem:
Ich betrachte Routing aus sicht eines Netzwerkes mit vielen Subnetzen, vielen Routern und vielen möglichen Wegen von Quelle zum Ziel. Also das was man im Netzwerk - egal welches Protokoll TCP/IP, SPX/IPX, ATM usw - entsprechend dem OSI-Referenzmodel vorfindet.
Du schaust Dir den PC an und wie dort intern Datenpakete gehändelt werden. Das ist etwas ganz anderes. Und damit haben wir allein schon bei den Begriffen ein Problem!
Routen ist OSI-Referenzmodel eindeutig definiert und hat mit Deiner Interpretation nichts zu tun.
Da der TO ja eine Cisco-Schulung macht, gebe ich Dir Brief und Siegel drauf, dass sich Cisco an die Nomenklatur des OSI-Referenzmodels hält. Und da routet ein Router und nicht irgend ein beliebiger Host mit einer IP-Adresse.
Aber ich will ja gerne noch dazu lernen. Erkläre mir dann doch mal, wie ein billiger L2-Switch mit Management-Interface oder ein Drucker mit LAN-Anschluß "routet". Und komm mir jetzt nicht damit, dass da ja eigentlich immer ein Embedded-Linux drauf läuft.
Und wen Du schon mal dabei bist: Kann ich meinen DrayTek-Router eigendlich einsparen und statt dessen meinen Tintenstrahldrucker mit LAN- und WLAN-Anschluß als Router einsetzen?
Jürgen
Moin,
Jetzt hast du es ;) Ich rede von "realem" Routing :D Und Wikipedia, zumindest die englische Version, sieht das ebenso und differnziert zwischen Routing und Forwarding. https://en.wikipedia.org/wiki/Routing
Ersteres macht eigentlich jeder Client, letzteres ist eher unüblich und auch der Grund, warum du ohne ziemlich abgefahrenen Mist zu machen, du deinen Drucker leider nicht als Router nutzen kannst, obwohl er routen kann!
Aber gut, gehen wir in den formalen Bereich und schauen uns den originalen Cisco O-Ton an:
So. Jetzt achte man auf den Unterschied zwischen ROUTING und ROUTER. ROUTING ist ein Vorgang, zum Wahl des Pfades, ROUTER ist ein Device, welches diesen "Service" für andere Geräte im Netz bereit stellt. Anders ausgedrückt: Dein Host ist für sich selbst der 0. Hop, stellt aber für andere Netzteilnehmer kein Routing-Service zur Verfügung. -> ROUTING: Ja ROUTER: Nein. Q.E.D.
Und deshalb musst du leider weiterhin deinen Router nutzen und kannst nicht ohne weiteres deinen Tintenstrahldrucker zum Forwarding von Paketen nutzen ;)
Gruß
Chris
Jetzt hast du es ;) Ich rede von "realem" Routing :D Und Wikipedia, zumindest die englische Version, sieht das ebenso und differnziert zwischen Routing und Forwarding. https://en.wikipedia.org/wiki/Routing
Ersteres macht eigentlich jeder Client, letzteres ist eher unüblich und auch der Grund, warum du ohne ziemlich abgefahrenen Mist zu machen, du deinen Drucker leider nicht als Router nutzen kannst, obwohl er routen kann!
Aber gut, gehen wir in den formalen Bereich und schauen uns den originalen Cisco O-Ton an:
Routing - The network layer provides services to direct packets to a destination host on another network. To travel to other networks, the packet must be processed by a router. The role of the router is to select the best path and direct packets toward the destination host in a process known as routing. A packet may cross many intermediary devices before reaching the destination host. Each router a packet crosses to reach the destination host is called a hop.
Quelle: https://static-course-assets.s3.amazonaws.com/ITN51/en/index.html#6.1.1. ...So. Jetzt achte man auf den Unterschied zwischen ROUTING und ROUTER. ROUTING ist ein Vorgang, zum Wahl des Pfades, ROUTER ist ein Device, welches diesen "Service" für andere Geräte im Netz bereit stellt. Anders ausgedrückt: Dein Host ist für sich selbst der 0. Hop, stellt aber für andere Netzteilnehmer kein Routing-Service zur Verfügung. -> ROUTING: Ja ROUTER: Nein. Q.E.D.
Und deshalb musst du leider weiterhin deinen Router nutzen und kannst nicht ohne weiteres deinen Tintenstrahldrucker zum Forwarding von Paketen nutzen ;)
Gruß
Chris
Hallo @Sheogorath,
ok, ein ROUTER ist ein IP-Device (Host), das die Funkion des ROUTINGs ausführt. Dacor.
Dann gilt aber auch: Ein ROUTER, der NICHT die Funktion des ROUTINGs ausübt, ist KEIN ROUTER.
Sonst kann ich ja auch sagen, mein Toaster ist ein Auto, welches die Funktion des Selbstfahrens nicht ausübt.
Ein Router ist im OSI-Referenzmodel ein genau definiertes Gerät mit entsprechenden Funktionen. Genauso wie Bridge, Hub, Gateway, Switch usw.
HOP ist die Anzahl der "übersprungenden" Router von Quelle zum Ziel! Wenn ich also in der Routingtabelle die Info habe, dass das Ziel mit 0 Hops erreichbar ist, heißt das, das Ziel ist im eigenen Subnetz.
Steht dort 1 Hop, ist zwischen Quelle und Ziel ein Router zu "überspringen". Und so weiter.
Jürgen
PS: Jetzt ist Wochenende.
ok, ein ROUTER ist ein IP-Device (Host), das die Funkion des ROUTINGs ausführt. Dacor.
Dann gilt aber auch: Ein ROUTER, der NICHT die Funktion des ROUTINGs ausübt, ist KEIN ROUTER.
Sonst kann ich ja auch sagen, mein Toaster ist ein Auto, welches die Funktion des Selbstfahrens nicht ausübt.
Ein Router ist im OSI-Referenzmodel ein genau definiertes Gerät mit entsprechenden Funktionen. Genauso wie Bridge, Hub, Gateway, Switch usw.
HOP ist die Anzahl der "übersprungenden" Router von Quelle zum Ziel! Wenn ich also in der Routingtabelle die Info habe, dass das Ziel mit 0 Hops erreichbar ist, heißt das, das Ziel ist im eigenen Subnetz.
Steht dort 1 Hop, ist zwischen Quelle und Ziel ein Router zu "überspringen". Und so weiter.
Jürgen
PS: Jetzt ist Wochenende.
@119944, @maxmax
Meine Aussage:
Wenn der Empfänger in einem anderen Subnetz ist und er schon mal erfolgreich ein Route dorthin über einen Router ermittelt hat, dann merkt er sich die MAC des Roters zu dieser IP damit er beim nächsten Paket dieses gleich an diese MAC senden kann ohne vorher wieder zu berechnen, dass das Ziel in einem anderen Subnetz ist und welche MAC der zuständige Router hat.
Ich habe mir jetzt nochmal die Mühe gemacht und das alles nochmal nachgelesen. Meine o.g. Aussage bzgl. ARP Cache und Routing ist so komplett falsch. Das habe ich mit ARP Proxy durcheinander gebracht.Wenn der Empfänger in einem anderen Subnetz ist und er schon mal erfolgreich ein Route dorthin über einen Router ermittelt hat, dann merkt er sich die MAC des Roters zu dieser IP damit er beim nächsten Paket dieses gleich an diese MAC senden kann ohne vorher wieder zu berechnen, dass das Ziel in einem anderen Subnetz ist und welche MAC der zuständige Router hat.
Ich verstehe den Sinn nicht, der PC/die Station weiß ja sowieso durch die IP/SM bereits dass diese Station in einem anderen Subnetz ist und das Paket deshalb ans Gateway gesendet werden muss. Wieso wird dann ein ARP-Eintrag angelegt.
Ja, es wird ein Eintrag in den ARP Cache vorgenommen, aber der ist für die IP des Routers plus der MAC des Routers.
