Subnet Frage (basics)

Sloop

Neuling
Thread Starter
Mitglied seit
14.06.2009
Beiträge
912
Hallo,

vielleicht eine doofe Frage, aber ich kann leider keine Antwort darauf finden. Einfaches Beispiel:

Host(A) hat die IP 192.168.10.88 und Subnet mask 255.255.255.0.

Er befindet sich also im 192.168.10.0 Netz mit 'ner 24er Maske, ClassC. In diesem Subnet sind alle Hosts miteinander gekoppelt, von 192.168.10.1 bis 192.168.10.254


Host(B) hat die IP 192.168.5.33 und Subnet mask 255.255.240.0. Dieses Netz beginnt also bei 192.168.5.1 und hört bei 192.168.20.254 auf.

Meine Frage: Wenn Host(B) nun einen Ping auf die 192.168.10.88 absetzen würde, hätte er Kontakt zu Host(A) ??? Denn das Subnetz von Host(A) wäre ja im Netz des Hosts(B) auch dabei. Und wenn ja, könnte auch Host(A) den Host(B) erfolgreich anpingen?

Host(A) 192.168.10.88 / 255.255.255.0 <-------------> Host(B) 192.168.5.33 / 255.255.240.0

Ich hoffe ihr versteht was ich meine, ist bisschen blöd erklärt vielleicht :S
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
da du aber einmal eine /24 und einmal eine /20 maske hast musst du Routen um ins andere Netz zu kommen!

lies dich da nochmal ein!

http://de.wikipedia.org/wiki/Netzmaske

Du musst dir das mal so denken, die IP ist die Adresse, und die Maske die Postleitzahl, so kann es zwar sein, das beide Häuser in der Testgasse 12 stehen, aber in einer komplett anderes Stadt!
und die Städte werden von der Post verbunden, die sich mit den "masken" Postleitzahlen auskennt, also ist die Post der Router !
 
Zuletzt bearbeitet:
Das Prinzip aus dem von dir geposteten Link ist mir klar, da habe ich auch kein Verständnisproblem (natürlich muss IP-Forwarding aktiviert sein).

Wird das sicher nicht funktionieren?? Natürlich ist mir bewußt, dass hier zwei verschiedene Subnets verwendet werden, aber schaut euch doch mal die Maske nochmals an. Die Maske des Hosts(B) überschneidet/berührt doch die des Hosts(A).

Das würde also dann bedeuten, dass sich folgende Hosts untereinander (ohne dazwischengeschaltetem Router/Gateway) nicht unterhalten können, obwohl sie dieselbe Subnetmaske verwenden, oder wie?

MaxClient1= IP:172.16.5.123 Mask:255.255.252.0
UdoClient2= IP:172.16.6.234 Mask:255.255.252.0

??
 
Zuletzt bearbeitet:
Das was Hardwarekenner sagt, ist völlig Korrekt.

Also Du verpasst Host (A) eine zweite IP und zwar: 192.168.5.0 oder mußt 192.168.5.1 benutzen.
Und dazu die Subnet Maske 255.255.240.0.
Dann richtest Du die Routen auf Host A ein und für Host B noch den Gateway 192.168.5.0 o. 192.168.5.1 ein.

So wie in dem Link den ich gepostet habe.

MfG

Peter
 
Zuletzt bearbeitet:
Oh, mein überarbeiteter Beitrag hat sich mit euren Postings überschnitten. Vielleicht könntet ihr noch auf meine letzte Frage eingehen, ich denke dann hab ichs begriffen :)
 
Wenn die Subnet Maske gleich ist, ist auch das Netz gleich und somit die Kommunikation gegeben ist.

Sind die Subnet Masken = Netz nicht identisch, ist keine Kommunikation ohne Router möglich.

Beispiel 2: 172.16.0.0/16 und 172.16.0.0/24 unterscheiden sich dadurch, dass das erste Netz die IP-Adressen 172.16.0.1 bis 172.16.255.254 umfasst, während das zweite nur den Bereich 172.16.0.1 bis 172.16.0.254 beinhaltet.
Quelle: http://de.wikipedia.org/wiki/Netzmaske

Somit wäre die Subnet Maske in dem Fall für 172.16.0.0/16: 255.255.0.0.
http://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing


MfG

Peter
 
Zuletzt bearbeitet:
Schön und gut BdMDesign, aber das hat mit meiner letzten Frage nichts zu tun. Meine Frage lautete:

MaxClient1= IP:172.16.5.123 Mask:255.255.252.0
UdoClient2= IP:172.16.6.234 Mask:255.255.252.0

Können diese zwei Hosts miteinander kommunizieren oder nicht? Sie liegen in verschiedenem Netz, haben aber die gleiche Subnetmaske, und der Bereich überlappt sich.
 
Zuletzt bearbeitet:
Ja und es geht nicht mit der Subnet Maske 255.255.252.0 sondern nur mit der Subnet Maske 255.255.0.0

Siehe auch hier: Classless Inter-Domain Routing

Dort ist es mit den Subnet Masken erklärt.

Also mit der 255.255.252.0 ist nur die Komunikation der IPs 172.16.5.XXX möglich, nicht aber mit den 172.16.6.XXX
Mit der 255.255.0.0 ist die Komunikation im IP Adressraum 172.16.XXX.XXX möglich.

P.S.: Vergesse mal das mit den Überlappen der IPs und der Subnet Maske.

MfG

Peter
 
Zuletzt bearbeitet:
Schön und gut BdMDesign, aber das hat mit meiner letzten Frage nichts zu tun. Meine Frage lautete:

MaxClient1= IP:172.16.5.123 Mask:255.255.252.0
UdoClient2= IP:172.16.6.234 Mask:255.255.252.0

Können diese zwei Hosts miteinander kommunizieren oder nicht? Sie liegen in verschiedenem Netz, haben aber die gleiche Subnetmaske, und der Bereich überlappt sich.

Ja, können sie - liegen beide im Subnetz 172.16.4.0 255.255.252.0...

Ich weis nicht, was du mit überlappen meinst - ich glaub du hast da noch was nicht verstanden...


Ja und es geht nicht mit der Subnet Maske 255.255.252.0 sondern nur mit der Subnet Maske 255.255.0.0
Quatsch...
 
Zuletzt bearbeitet:
Wenn wir noch mal auf deine erste Konfiguration zu sprechen kommen,

also:

Host a) 192.168.10.88 und Subnet mask 255.255.255.0
Host b) 192.168.5.33 und Subnet mask 255.255.240.0

Dann kann Host b auf jedenfall Host a) erreichen, wird aber keine Rückantwort von Host a bei einem TCP Handshake erhalten können, da a über einen Router gehen müsste, der das große Netz abzufrühstücken wüsste! UDP Verbindungen hingegen sollten funktionieren, da diese Verbindunglos sind.


Host b möchte Host a erreichen. Also schaut er in die Routingtabelle und merkt: Hey, den kann ich direkt erreichen, da er im selben Subnetz ist. Host b kann Host a z.B. direkt nach seiner Mac Adresse mit einem ARP Request fragen.
Host a möchte Host b erreichen. Host a schaut in Routing Tabelle nach... Mist, kenn ich nicht bzw liegt nicht in meinem Subnetz, dann muss ich wohl über einen Router. Host a könnte theoretisch auch nach der IP via ARP Request fragen. Tut dies aber nicht, da Host b nicht in seinem Subnetz ist.
 
@ FlintX:

Was ist daran Quatsch?

MaxClient1= IP:172.16.5.123 Mask:255.255.252.0
UdoClient2= IP:172.16.6.234 Mask:255.255.252.0

Laut der Tabelle: Classless Inter-Domain Routing ist es die Falsch Subnetz Maske um eben beide IP Adressräume unter einen Subnetz anzusprechen.

MfG

Peter



Vertuh dich da mal nich!

Host address - 172.16.5.123
Network address - 172.16.4.0
Network mask - 255.255.252.0
Broadcast address - 172.16.7.255
Network range - 172.16.4.0 - 172.16.7.255
Usable range - 172.16.4.1 - 172.16.7.254


Sie liegen also sehr wohl im selben Netzbereich
 
Ok, dann kann ich der Liste in der Wiki nicht mehr trauen.

MfG

Peter

Warum nicht trauen? :) In einem /22 sind 1024 Adressen.

Die ersten 1024 von
172.16.0.0 bis 172.16.3.255
und die weiteren 1024
172.16.4.0 bis 172.16.7.255

Passt doch laut Wiki Tabelle ;)
 
Wieso kann man der Tabelle nicht trauen?

3. Segment
252 - 11111100

1. Netz 0-3
2. Netz 4-7
3. Netz 8-11

Passt doch alles.

Wir sind im 2. netz, 5 und 6 liegen zwischen 4 und 7. ;)
 
Dann kann Host b auf jedenfall Host a) erreichen, wird aber keine Rückantwort von Host a bei einem TCP Handshake erhalten können, da a über einen Router gehen müsste, der das große Netz abzufrühstücken wüsste! UDP Verbindungen hingegen sollten funktionieren, da diese Verbindunglos sind.
Nö, UDP geht auch nicht... Rückantworten von a an b gehen immer verloren, da das Gateway fehlt.

Host b möchte Host a erreichen. Also schaut er in die Routingtabelle und merkt: Hey, den kann ich direkt erreichen, da er im selben Subnetz ist. Host b kann Host a z.B. direkt nach seiner Mac Adresse mit einem ARP Request fragen.
Host a möchte Host b erreichen. Host a schaut in Routing Tabelle nach... Mist, kenn ich nicht bzw liegt nicht in meinem Subnetz, dann muss ich wohl über einen Router. Host a könnte theoretisch auch nach der IP via ARP Request fragen. Tut dies aber nicht, da Host b nicht in seinem Subnetz ist.

Obacht, das hat nix mit der Routingtabelle zu tun...
Der Client wird anhand der Subnetzmaske und der beiden IPs schlicht berechnen, ob die Zieladresse in seinem eigenen Subnetz ist oder nicht...
Ist sie das, wird mittels ARP die MAC-Adresse erfragt, nicht die IP (Die kennt der Client ja schon), und anschliessend der Frame übertragen...

Ist die Adresse in einem anderen Netz, geht das Paket auf die gleiche Weise an den entsprechenden Router, der es dann weiter vermittelt...
 
Nö, UDP geht auch nicht... Rückantworten von a an b gehen immer verloren, da das Gateway fehlt.

UDP funktioniert natürlich nur in die eine Richtung. Eine Rückantwort gibts natürlich auch per UDP nicht. Ich meinte damit ehr, dass man zu mindest mehr senden kann, als bei TCP, wo selbst für den Verbindungsaufbau der Rückweg bekannt sein muss.

Obacht, das hat nix mit der Routingtabelle zu tun...
Der Client wird anhand der Subnetzmaske und der beiden IPs schlicht berechnen, ob die Zieladresse in seinem eigenen Subnetz ist oder nicht...
Ist sie das, wird mittels ARP die MAC-Adresse erfragt, nicht die IP (Die kennt der Client ja schon), und anschliessend der Frame übertragen...

Ist die Adresse in einem anderen Netz, geht das Paket auf die gleiche Weise an den entsprechenden Router, der es dann weiter vermittelt...

In der Routing Tabelle wird schon nach geschaut. Denn es gibt immer noch den Fall, dass beispielsweise eine Route für ein kleineres Netz innerhalb des eigenen Netze auf dem Rechner vorhanden ist! Und dann gilt eben die "most specific route".

Mit ARP Request und MAC, stimmt natürlich... Wollte ich eigtl auch schreiben... Gedankengulasch :fresse:


Als Beispiel gerade mal auf meinem Server getestet:
Server: 10.0.0.5
Gateway: 10.0.0.1 via VRRP abgesichert. D.h. die IPs 10.0.0.2 und 10.0.0.3 sind ebenfalls pingbar und als Gateway nutzbar.


Routing Tabelle:
10.0.0.0/24 dev em1 proto kernel scope link src 10.0.0.2
default via 10.0.0.1 dev em1

Füge ich nun eine Route hinzu, die z.B. 10.0.0.2 via em2 rausbläst oder über ein nicht vorhandenes Gateway, dann pingt die IP schon nicht mehr!

ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
ping: sendmsg: Die Operation ist nicht erlaubt
ping: sendmsg: Die Operation ist nicht erlaubt
^C
--- 10.0.0.2 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms
 
In der Routing Tabelle wird schon nach geschaut. Denn es gibt immer noch den Fall, dass beispielsweise eine Route für ein kleineres Netz innerhalb des eigenen Netze auf dem Rechner vorhanden ist! Und dann gilt eben die "most specific route".

Uff, ja gut... das ist aus Netzwerksicht aber schon ne ganz schöne Sauerei - das baut normalerweise ja niemand freiwillig so auf ;)

Ich würde auch nicht drauf wetten, dass sich da jede Büchse so verhält... Bei nem Router z.B. würde ich meinen, dass er dem direkt verbundenen Subnetz eher glaubt als der Route, auch wenn sie spezifischer ist... Müsste man direkt mal testen, welche Regel da "wichtiger" ist... Mal schauen, ob ich morgen im Büro Zeit dazu finde...
 
Zuletzt bearbeitet:
Ich musste sowas leider bereits konfigurieren :( Auf Juniper Routern funktioniert es jedenfalls, leider...
 
Ich probiers morgen mal auf nem Cisco... aber wenn Juniper es macht, wirds bei Cisco wohl auch gehen :-)
 
der geht so ! EDIT: ihr seit schon weiter ?

Einführung in TCP/IP - TCP/IP im Detail: Transportschicht

---------- Post added at 00:06 ---------- Previous post was at 00:01 ----------

Uff, ja gut... das ist aus Netzwerksicht aber schon ne ganz schöne Sauerei - das baut normalerweise ja niemand freiwillig so auf ;)

Ich würde auch nicht drauf wetten, dass sich da jede Büchse so verhält... Bei nem Router z.B. würde ich meinen, dass er dem direkt verbundenen Subnetz eher glaubt als der Route, auch wenn sie spezifischer ist... Müsste man direkt mal testen, welche Regel da "wichtiger" ist... Mal schauen, ob ich morgen im Büro Zeit dazu finde...


also ein ordentlicher Router merkt sich doch die Hops (TTL) und wo das packet am schnellsten gelaufen ist, er muss dazu ja nicht alle netze kennen, nur das zu seinem "Nachbar Router" und wenn das packet sich nicht auflösst ist es durchgekommen, und dann merkt er sich die Route und gut ist!
 
Zuletzt bearbeitet:
Hi nochmal, und vor allem danke an Nascar und FlintX. Nix fuer ungut BdMdesign, aber lies dich bitte genau vorher ein, denn du hast mich schon verrueckt gemacht mit deinen Aussagen.

Nascar und Flintx, ihr seid jetzt natuerlich schon tiefgruendiger eingestiegen, weil ihr wohl Pings testen wolltet. Natuerlich wirds nur in eine Richtung funktionieren, da der anderen Host ja nicht zuruecktelefonieren kann. Aber ich hab das Prinzip verstanden, und nur darum gings mir. Es ist also tatsaechlich so, dass der eine Host den anderen in diesem Fall sieht, aber nicht umgekehrt.

Vielen Dank euch beiden. Gruesse und eine schoenes Wochenende.
 
Selbst zitiern rockt...
Ich probiers morgen mal auf nem Cisco... aber wenn Juniper es macht, wirds bei Cisco wohl auch gehen :-)

longest prefix match greift vor der administrative distance, sprich das würde so funktionieren. Wenn man bisserl drüber nachdenkt, machts auch Sinn...
 
@ Sloop:

Ich hab mich einfach nur mit der Subnet Maske geirrt.
Da ich von der /24 ausgegangen bin.
Ansonsten sind meine Aussagen Korrekt.

Da brauch ich mich nicht weiter einlesen, war aber auch schon Spät gestern.

MfG

Peter
 
@ Sloop:

Ich hab mich einfach nur mit der Subnet Maske geirrt.
Da ich von der /24 ausgegangen bin.
Ansonsten sind meine Aussagen Korrekt.

Da brauch ich mich nicht weiter einlesen, war aber auch schon Spät gestern.

MfG

Peter


Na, aber Du wirst schon dem TE zu gute halten, daß er das annehmen muß, denn Du hast Dich immerhin zweimal in der Subnetzmaske mit /24 "vertan".

Das ist schon fast so, als antwortet man auf eine nicht gestellte Frage.

@TE
Dein Begriff "Überlappen" ist hier ein wenig irreführend, da man letztlich im größeren Netz (bspw. /22) eine kleineres Netz (bspw. /24) betrachtet. Da kann man eher von beinhalten denn von überlappen sprechen, denn letztlich befindet sich das kleinere vollständig im größeren Netz.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh