in welchem Fall gibt es in einer Traceroute-Ausgabe zwei Nachbar-Hops im selben Subnetz? Soweit ich weiß, sollten es nur Quelladressen sein und jede Router-Schnittstelle sollte sich in einem anderen Subnetz befinden?
Z.B:
1 * * * Request timed out.
2 2 ms 3 ms <3 ms 10.10.0.14
3 5 ms 4 ms 3 ms 10.10.0.15
4 21 ms 22 ms 25 ms 194.221.100.49
Es sollte ungefähr so aussehen.
(PC) 192.168.1.2 --- 192.168.1.1 (Router1) 10.10.0.X --- 10.10.0.14 (Router2) 10.10.0.x --- 10.10.0.15 (Router3) 192.221.100.X --- 192.221.100.49 (Router4) X.X.X.X
Aber im Router2 gibt es 2 Schnittstellen im selben Subnetz, was nicht möglich sein sollte?
Um welche Konfiguration könnte es sich handeln? Vielleicht Frame Relay?
Antwort1
Sollte sich jede Routerschnittstelle in einem anderen Subnetz befinden?
Der Fehler in Ihrer Logik liegt in der Annahme, dass Netzwerktopologien immer Router beinhalten, die Pakete, die über eine Schnittstelle in einem Subnetz empfangen werden, strikt über eine Schnittstelle weiterleiten, die in einem anderen Subnetz definiert ist. Während das in üblichen SOHO- und mittelständischen Umgebungen zutrifft, ist es nicht dienurMöglicher Bereitstellungsmodus verfügbar. Netzwerktechniker haben möglicherweise Gründe, einen anderen Ansatz zu wählen, oder sie könnten durch Glück und Konfigurationsschwankungen versehentlich dafür sorgen, dass ein bestimmter Ansatz gewählt wird.
Es gibt mehrere Szenarien, in denen ein Router Pakete empfangen kann, die anschließend an dasselbe Netzwerk zurückgeleitet werden, in dem sie empfangen wurden. Es ist wichtig, wie und in Bezug auf welches Gerät wir unsere Subnetze definieren. Beispielsweise ist es völlig zulässig, dass ein Router eine Schnittstelle von hat 10.0.0.1/16, während Geräte dahinter Adressen im Subnetz verwenden 10.0.x.y/24. Aus Sicht des Geräts müssten Pakete von 10.0.1.x bis 10.0.2.x einen oder mehrere Router durchlaufen, aber der Router weiß es besser. Dieses Phänomen derNetzwerkposaunenist häufig im Kern von Unternehmensnetzwerken zu finden. Es ist zwar nicht unbedingt effizient, aber es funktioniert und der Router erledigt seine Aufgabe ordnungsgemäß.
Ein weiteres häufiges Vorkommnis tritt auf, wenn ein Traceroute von einem Gerät ausgeführt wird, das mit einem VPN-Konzentrator verbunden ist, der seinen Datenverkehr über das VPN zum Remote-Gerät tunnelt. Wenn wir annehmen, dass dies die Ursache für Ihre Traceroute-Ausgabe war, .14wäre das Gerät wahrscheinlich der Konzentrator, der mit dem Firmen-LAN am Remote-Ende verbunden ist. Das .15Gerät ist der Router für das Netzwerk, mit dem der Konzentrator verbunden ist. Pakete werden über die Schnittstelle empfangen (getunnelt) .14und über dieselbe Schnittstelle wieder ausgegeben, um an ihr Ziel weitergeleitet zu werden. Daran ist nichts auszusetzen und traceroutees zeigt Ihnen legitimerweise die Identitäten aller Geräte, die für die Verarbeitung der Pakete auf der IP-Ebene verantwortlich sind.
Ohne weitere genaue Kenntnisse der Netzwerktopologie und insbesondere der Konfiguration des/der Zwischenrouter(s) ist es unmöglich, genau zu verstehen, was in Ihrem Fall passiert.
Antwort2
Traceroute funktioniert, indem es effektiv einen Ping mit einer TTl (Time to Live) von 1 sendet. Es trifft den ersten Router, der mit einer ICMP-Time-Exceeded-Meldung antwortet. Dies wird wiederholt, in Ihrem Fall insgesamt dreimal.
Dann sendet es 3 Pings mit einem TTL von 2, dann 3 usw. Es zeigt die Antwort jedes Routers als Route zum Host an.
https://en.wikipedia.org/wiki/Traceroute
Meine erste Vermutung ist, dass, wenn Ihr System richtig konfiguriert ist, Ihr erster Router (der so konfiguriert ist, dass er die Meldung „Zeit überschritten“ nicht sendet) einen Standardpfad zu 10.10.0.14 hat, der eine statische Route zum Subnetz 194.221.100.49 deklariert hat