pingen = timeout wieso?

[RobinWi436]

Hallo, Leute. Ich versuche den Router 2 von dem Pc anzupingen, aber ich kriege immer einen timeout, wieso? Ich kann den Router 2 von Router 1 anpingen, aber vom Pc aus nicht.

 

[madmax2010]

hast du da 1 route hin? sehe da nur interface configs

 

[0x8100]

routet router1 denn auch wirklich? nur weil er zwei interfaces in beiden netzen hat, heisst das ja nicht automatisch, dass er zwischen denen auch weiterleitet.

 

[Stratotanker]

Da scheint sich jemand in Routing & Switching einzuarbeiten? 1. Dein PC benötigt auf jeden Fall eine Rote zum R2. Ob die als Default- oder more specific eingerichtet wurde, ist egal. Da R1 in jedem Netz ein Interface hat, benötigt er keine weitere Route. R2 wiederum benötigt, korrekte Rückrouten zum PC mit R1 als next-hop. Zeig mal bitte die "ip route" Einträge.

 

[Raijin]

Abgesehen vom Routing, das sich in dieser Konstellation mit den Stansardrouten erschlagen ließe (wir sehen ja die Routingtabellen nicht und können daher nur mutmaßen), spielt natürlich auch die Firewall ďer beteiligten Geräte eine Rolle. Der PC wird ausgehend nicht eingeschränkt sein, Router 1 beim durchrouten tendenziell auch nicht, aber Router 2 bekommt einen Echo-Request mit einer Absende-IP aus dem 146.66er Subnetz und das liegt außerhalb seines eigenen 128er Subnetzes. Eine restriktive Firewall würde das blockieren.

Minimal-Routing =>
PC : Standardgateway 146.66.1.1 (ist schon gesetzt)
Router1 : Hat bereits 2 Interface-Routen durch seine beiden IPs
Router2 : Standardgateway 128.1.1.1 oder Subnetzroute 146.66.0.0/16 via 146.66.1.1
(Router2 : Firewall => allow icmp in @ src=all)


Übrigens: Beide Subnetze sind schlecht gewählt und das 146.66er zudem noch schlecht besetzt. Beide liegen außerhalb der RFC1918 Range, sind also nicht für private Netze reserviert und somit im www potentiell bereits belegt. Sowas sollte man sich gar nicht erst angewöhnen, auch nicht in reinen Testnetzwerken oder gar nur in Packet Tracer, o.ä.. Bitte einfach NIE so machen...
Darüber hinaus sitzt Router 1 mittendrin im Subnetz. Es kann natürlich sein, dass Router 1 als weiteres Gateway innerhalb eines großen Netzwerks neben dem zentralen Standardgateway coexistieren soll, aber zumindest am PC dient Router 1 als Standardgateway. Zwar ist es kein MUSS, dass der Router die erste Host-IP im Subnetz bekommt, aber es ist gängige Praxis und altbewährt. Die "korrekte" IP wäre daher die 146.66.0.1, weil das /16er Subnetz dort nun mal beginnt (Subnetzadresse 146.66.0.0/16)


Übrige

 

[RobinWi436]

Braucht ihr das hier?

 

[0x8100]

router2 hat wohl kein default-gateway (extrem abschnitten "gateway of last resort is not set") und er hat keine rückroute ins 146.66.0.0/16 netz. selbst wenn der ping also an router2 ankommt, weiss dieser nicht, wohin er die antwort schicken soll. sieht so aus, als ob @Stratotanker gewonnen hat

 

[Stratotanker]

Danke @0x8100. Jepp , Router 2 hat keine Ahnung bzw Route wie er zum PC kommen soll. Mit einen "show ip route 146.66.20.20" wirst du die Antwort "subnet not in table bekommen. Da er auch keine default route hat, wird das Paket verworfen.

 

[RobinWi436]

ip route 146.66.0.0 255.255.0.0 146.66.1.1 <--- Wenn ich das in Router 2 eingebe , dann wird das in der Routenliste garnicht eingetragen. Das ist doch die Route die ich brauche oder?

 

[0x8100]

wenn du das 146.66.0.0/16 netz erreichen willst, kannst du nicht 146.66.1.1 als gateway angeben, denn das liegt im gleichen netz. es wäre ip route 146.66.0.0 255.255.0.0 128.1.1.1 denn dieses gateway ist auch tatsächlich von router2 aus erreichbar.

 

[Raijin]

Yep, das war ein typo von mir in #5. Natürlich muss das Gateway von Router2 aus ins 146.66er Subnetz die 128er IP von Router1 sein (so wie ich es als Standardgateway geschrieben hatte)

 

[Hammelkoppter]

Moin,
da haste Dir gleich nen klassisches Problem raus gepickt. Ohne zu lesen hatte ich gleich den Tipp, dass die Rückroute fehlt. Glaub mir - das wird dir im Netzwerkerleben noch seeehr oft begegnen.

Folgenden Rat würde ich Dir an die Hand geben. Gewöhne dir gleich eine geordnete Methode zum Troubleshooting an. Nutze dazu das OSI Modell d.h. wenn irgendwas nicht funktioniert, fängst du an mit Layer 1 (Verkabelung) und arbeitest dich dann immer weiter nach oben. Layer 2 ist in deinem Fall kein Problem, da du nicht mit VLANs arbeitest (und auch sonst kein wildes Layer 2 Konstrukt im Pfad hast) und du ja den ersten Hop auch erreichen kannst. Dann kommst du zu Layer 3 (Routing). Hier musst du kontrollieren ob jedes Gerät im Pfad sowohl Hin als auch Rückroute kennen. Weiterhin würdest du hier auch die korrekte IP Adressierung aller Komponenten prüfen.

Und erst wenn das geprüft ist kommst du zu Firewallregeln etc.

Meist sind Probleme relativ einfach zu finden, wenn man geordnet vorgeht. Bitte nicht von Anfang an mit den wildesten Theorien beschäftigen und sich dann verzetteln.

...und wenn man dann ein paar Jahre Netzwerk gemacht hat kann man auch mal auf ein Problem tippen ohne vorher zu troubleshooten (wie ich es anfangs getan habe) einfach aus Erfahrung heraus. Klappt das nicht, geht man dann halt den geordneten Weg ;-)

Grüße

 

[Raijin]

In einer realen Umgebung oder in einem entsprechend ausgestatteten Netzwerksimulator kann man dann zB auch mit tcpdump o.ä. die Pakete an jeder Station aufzeichnen und den Weg verfolgen, wenn man durch scharfes Hinsehen auf die Routen, etc. nicht weiterkommt. Mit tcpdump am PC würde man mutmaßlich sehen, dass der Ping ordnungsgemäß abgeschickt wird, tcpdump an R1 würde den eingehenden Ping vom PC an f0/0 zeigen, f0/1 den ausgehenden Ping Richtung R2 und an R2 käme der Ping auch an, aber es würde kein Ping-Reply zu sehen sein, weil R2 nicht weiß wohin damit. Auf diese Weise würde man zB auch NAT beobachten können, wenn in R1 denn welches konfiguriert wäre, weil der Ping dann plötzlich die Quell-IP wechseln würde.

 

[RobinWi436]

Vielen Dank für eure Tipps Leute.