Routing Problem (Linux)
Dennis
- webserver
Hi alle,
ich hab hier einen PC mit Ubuntu 7.10 aufgesetzt, welcher als Router fungieren soll, um die Anbindung einzelner Netzwerke ans Internet herzustellen.
Dazu besitzt dieser Rechner mehrere Netzwerkkarten (genaugenommen 6 Stück, jetzt versuche ich aber erstmal 2 ans Laufen zu bekommen). Über die Netzwerkkarte eth6 besteht Anschluss zum Internet, dies funktioniert auch problemlos. Die Konfiguration lautet:
auto eth6
iface eth6 inet static
address 10.6.0.1
netmask 255.255.255.0
network 10.6.0.0
broadcast 10.6.0.255
gateway 10.6.0.2
dns-nameservers 10.6.0.2
Dieser Router selber soll also 10.6.0.1 sein, er hat über einen Hardware-Router (DSL) mit der IP 10.6.0.2 Zugang zum Internet.
Nun soll über die Netzwerkkarte eth0 eine Anbindung an ein Netzwerk erfolgen, in welchem alle Client-PCs die IPs 10.7.0.XXX haben und so konfiguriert sind, dass sie 10.7.0.1 als Gateway benutzen. Folglich habe ich auf diesem Router folgende Konfiguration hinzugefügt:
auto eth0
iface eth0 inet static
address 10.7.0.1
netmask 255.255.255.0
network 10.7.0.0
broadcast 10.7.0.255
So sieht route -n
jetzt aus:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.6.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth6
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 10.6.0.2 0.0.0.0 UG 100 0 0 eth6
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth
Nun zu meinem Problem: Die Kommunikation im 10.7.0.XXX Netz funktioniert nicht. Gebe ich an einem Client-PC ping 10.7.0.1
ein (also zum Router), so schlagen alle Ping-Pakete fehl. Gebe ich am Router ein ping zu einem Client an, z.B. ping 10.7.0.24
so schlägt auch hier alles fehl.
Woran liegt das? Was mache ich falsch?
Viele Grüße,
~ Dennis.
hallo,
Dazu besitzt dieser Rechner mehrere Netzwerkkarten (genaugenommen 6 Stück, jetzt versuche ich aber erstmal 2 ans Laufen zu bekommen)
Ups. Wozu brauchst du gleich 6 Netzwerkkarten? Es wäre empfehlenswert, vier davon zumindest vorläufig auszubauen, damit dir die Zählung nicht durcheinandergerät.
auto eth6
Das müßtest du weglassen können. Es kann - abhängig von deiner Hardware und den installierten Paketen - sinnvoll sein, zusätzlich ein
allow-hotplug eth(x)
einzufügen.
Nun soll über die Netzwerkkarte eth0 eine Anbindung an ein Netzwerk erfolgen, in welchem alle Client-PCs die IPs 10.7.0.XXX haben und so konfiguriert sind, dass sie 10.7.0.1 als Gateway benutzen.
Wie erfolgt diese Anbindung? Wenn es mehrere Rechner sind, müßten die über einen eigenen Hub angeschlossen werden.
address 10.7.0.1
netmask 255.255.255.0
Ich weiß nicht, ob diese "netmask" sehr glücklich gewählt ist. Wenn es Probleme gibt, würde ich es zunächst mit 255.0.0.0 versuchen.
Nun zu meinem Problem: Die Kommunikation im 10.7.0.XXX Netz funktioniert nicht. Gebe ich an einem Client-PC
ping 10.7.0.1
ein (also zum Router), so schlagen alle Ping-Pakete fehl.
Welches Betriebssystem hat denn dein Client? Davon ist ein bißchen abhängig, welche Diagnosemöglichkeiten (logs) es gibt.
Gebe ich am Router ein ping zu einem Client an, z.B.
ping 10.7.0.24
so schlägt auch hier alles fehl.
Es gibt aber wenigstens ein bißchen Fehlermeldung. Beispielsweise "network is unreachable" oder Ähnliches.
Grüße aus Berlin
Christoph S.
Hi Christoph,
Ups. Wozu brauchst du gleich 6 Netzwerkkarten? Es wäre empfehlenswert, vier davon zumindest vorläufig auszubauen, damit dir die Zählung nicht durcheinandergerät.
Weil dieser Router am Ende 5 Netzwerken die Möglichkeit geben soll, über ein anderes Netzwerk (das sechste) Zugang zum Internet zu erhalten.
Wie erfolgt diese Anbindung? Wenn es mehrere Rechner sind, müßten die über einen eigenen Hub angeschlossen werden.
Alle Clients (IPs von 10.7.0.10 bis 10.7.0.26) sind an einem Gigabit-Switch angeschlossen, an welchem auch der Router (10.7.0.1) dranhängt. Die Clients können sich untereinander anpingen, allerdings den Router nicht, ebenso wie der Router die Clients nicht.
Ich weiß nicht, ob diese "netmask" sehr glücklich gewählt ist. Wenn es Probleme gibt, würde ich es zunächst mit 255.0.0.0 versuchen.
Nun ja, die Netmask ist zumindest an allen Clients und am Router gleich eingestellt ;-)
Welches Betriebssystem hat denn dein Client? Davon ist ein bißchen abhängig, welche Diagnosemöglichkeiten (logs) es gibt.
Alle Clients sind Windows XP SP2, während der Router wie bereits erwähnt ein Ubuntu 7.10 ist und über eth6 Zugang zum Internet hat (ich sitze grade am Router).
Es gibt aber wenigstens ein bißchen Fehlermeldung. Beispielsweise "network is unreachable" oder Ähnliches.
root@Router:/etc/network# ping 10.7.0.10
PING 10.7.0.10 (10.7.0.10) 56(84) bytes of data.
From 10.7.0.1 icmp_seq=1 Destination Host Unreachable
From 10.7.0.1 icmp_seq=2 Destination Host Unreachable
[...]
--- 10.7.0.10 ping statistics ---
13 packets transmitted, 0 received, +9 errors, 100% packet loss, time 12007ms, pipe 3
Viele Grüße,
~ Dennis.
hallo,
Alle Clients sind Windows XP SP2, während der Router wie bereits erwähnt ein Ubuntu 7.10 ist und über eth6 Zugang zum Internet hat (ich sitze grade am Router).
Hm. Eventuell spielt da die Windows-Firewall irgendwie nicht mit.
Ich habe grade mal meine Rechner verglichen: auch da habe ich einen mit Debian und einen mit WindowsXP, die in demselben Netz (bei mir 192.168.0) hängen. Auch da funktioniert es mit dem Ping nicht, was mich allerdings nicht weiter stört, deswegen habe ich das nie problematisiert. Auf beiden Rechnern ist jeweils ein Apache installiert, und die können durchaus gegenseitig aufgerufen werden.
ping benutzt ein anderes Protokoll - ICMP. Schau mal, ob dir "man icmp" irgendwas sagt.
Grüße aus Berlin
Christoph S.
Hello,
Alle Clients (IPs von 10.7.0.10 bis 10.7.0.26) sind an einem Gigabit-Switch angeschlossen, an welchem auch der Router (10.7.0.1) dranhängt. Die Clients können sich untereinander anpingen, allerdings den Router nicht, ebenso wie der Router die Clients nicht.
Dann würde ich doch mal nach der Netzwerkmaske schauen, aber bei den Clients.
Da muss die dann ja genauso aussehen, wie beim Routing Host, wenn sie zu denselben Netzen gehören sollen (ohne Tricks).
Wenn das WinXP sind, werden die bei 10.x.x.x automatisch auf 255.0.0.0 springen als Vorschlag. Wenn Dir das entgangen ist, gehören sie eben nicht zum selben Netz.
Harzliche Grüße vom Berg und Frohe Weihnachtszeit
Tom
Hallo Tom,
Dann würde ich doch mal nach der Netzwerkmaske schauen, aber bei den Clients.
Da muss die dann ja genauso aussehen, wie beim Routing Host, wenn sie zu denselben Netzen gehören sollen (ohne Tricks).Wenn das WinXP sind, werden die bei 10.x.x.x automatisch auf 255.0.0.0 springen als Vorschlag. Wenn Dir das entgangen ist, gehören sie eben nicht zum selben Netz.
Das stimmt so pauschal nicht. Auch bei einer derart falsch konfigurierten Netzmaske auf den Clients (!) sollte das ping und der direkte Netzwerkzugriff dennoch funktionieren (hab's bei mir übrigens gerade getestet).
ALLERDINGS kann eine derartige Fehlkonfiguration zu anderen Problemen (insbesondere in Verbindung mit Routing) führen, daher ist Dein Hinweis, das nochmal zu kontrollieren, sicher angebracht, das Problem wird er jedoch nicht beseitigen.
Viele Grüße,
Christian
hallo Tom,
Wenn das WinXP sind, werden die bei 10.x.x.x automatisch auf 255.0.0.0 springen als Vorschlag.
Ja, als Vorschlag. Kannst du allerdings problemlos ändern.
Ping kümmert sich aber normalerweise nicht darum. Du kannst von deinem Rechner aus ohne weiteres Google oder einen der SELF-Server anpingen, und beide Adressen gehören vermutlich nicht demselben Netz an wie grade dein Rechner. Ping berücksichtigt aber einen vorhandenen DNS-Eintrag (z.B. in der lokalen hosts-Datei) oder bei Debian etwas, was in /etc/resolv.conf steht.
Wenn Dir das entgangen ist, gehören sie eben nicht zum selben Netz.
Wichtig _kann_ für die Netzwerkverbindung ein vorhandener Server (Samba auf dem Ubuntu-Router) oder eine vorhandene Firewall oder ein VPN-Client oder ein Proxy sein. Das sind alles Faktoren, die die direkte Rechnerverbindung beeinflussen können.
Grüße aus Berlin
Christoph S.
Hello,
Ping kümmert sich aber normalerweise nicht darum.
Es bnötigt aber eine freigeschaltete Route zum Kandidaten.
Wenn die in verschiedenen Netzen liegen, noch ein paar Router dazwischen sind, und keiner weiß wo die Kandidaten liegen, wie funktioniert das dann?
Harzliche Grüße vom Berg und Frohe Weihnachtszeit
Tom
Hallo Christoph,
Wenn das WinXP sind, werden die bei 10.x.x.x automatisch auf 255.0.0.0 springen als Vorschlag.
Ping kümmert sich aber normalerweise nicht darum. Du kannst von deinem Rechner aus ohne weiteres Google oder einen der SELF-Server anpingen, und beide Adressen gehören vermutlich nicht demselben Netz an wie grade dein Rechner.
Du wirfst hier einiges durcheinander. Selbstverständlich kann man Rechner anpingen, die nicht im eigenen Netzwerk sind. IP kümmert sich schon darum, dass die Pakete ankommen. Wenn das Routing jedoch versagt, dann kommt das Paket nicht an. Nach meiner Erfahrung ist Windows, was die Netzwerkmaske betrifft, fehlertolerant. Linux dagegen in aller Regel nicht.
Sprich: Ein Windows versucht auch den Netzwerkzugriff zu einer Gegenstelle, wenn diese laut Netzwerkmaske nicht im gleichen Netzwerk liegt, die Linux-Rechner, die ich bei solchen Fällen getestet habe, jedoch nicht. Mehr dazu findest Du im Archiv ...
Freundliche Grüße
Vinzenz
hallo Vinzenz,
Du wirfst hier einiges durcheinander.
Ich glaube nicht.
Wenn das Routing jedoch versagt, dann kommt das Paket nicht an.
Bei dem Beispiel von Dennis geht noch gar nicht um Routing, sondern darum, daß ein einzelner Rechner (in diesem Fall sein Ubuntu-Router) unerreichbar ist - und zwar mit der NIC, die zum selben (Sub-)Netz gehört wie alle anderen. Daß das Routing dann zusätzlich nicht klappen kann, ist eine Folgeerscheinung.
Ein Windows versucht auch den Netzwerkzugriff zu einer Gegenstelle, wenn diese laut Netzwerkmaske nicht im gleichen Netzwerk liegt
Windows schleppt als "Voreinstellung" auch immer noch NetBIOS mit.
Grüße aus Berlin
Christoph S.
Hallo Christoph,
Windows schleppt als "Voreinstellung" auch immer noch NetBIOS mit.
Du wirfst noch mehr durcheinander. NetBIOS benötigt kein TCP/IP. NetBIOS hat mit Ping nichts zu tun.
Freundliche Grüße
Vinzenz
hallo Vinzenz,
Windows schleppt als "Voreinstellung" auch immer noch NetBIOS mit.
Du wirfst noch mehr durcheinander.
Nein. Ich habe lediglich eine Ergänzung notiert.
NetBIOS benötigt kein TCP/IP. NetBIOS hat mit Ping nichts zu tun.
Richtig. Aber es hat etwas damit zu tun, daß sich Windows-Rechner untereinander in der "Netzwerkumgebung" erreichen können, während ein Linux-Rechenr außen vor bleibt.
Ping wiederum hat mit dem Routing nichts zu tun.
Grüße aus Berlin
Christoph S.
Hallo,
NetBIOS benötigt kein TCP/IP.
das "reine" NetBIOS nicht. Aber gibt's das in heutigen Windows-Versionen noch? Ich habe das zuletzt in Win9x gesehen. Seit Win2k gibt es doch nur noch "NetBIOS over TCP/IP", was auch in der Defaulteinstellung aktiv ist und verwendet wird - oder irre ich mich?
NetBIOS hat mit Ping nichts zu tun.
Nur insofern, als sie beide ein korrekt funktionierendes IP-Protokoll brauchen (NetBIOS over TCP/IP angenommen).
Schönes Wochenende noch,
Martin
Hallo Martin,
NetBIOS benötigt kein TCP/IP.
das "reine" NetBIOS nicht. Aber gibt's das in heutigen Windows-Versionen noch? Ich habe das zuletzt in Win9x gesehen. Seit Win2k gibt es doch nur noch "NetBIOS over TCP/IP", was auch in der Defaulteinstellung aktiv ist und verwendet wird - oder irre ich mich?
Du irrst Dich - nicht was die Defaulteinstellung von NetBT aka "NetBIOS over TCP/IP" angeht - NetBIOS über IPX/SPX oder NetBEUI wird prinzipiell immer noch unterstützt, das musst Du halt installieren.
Freundliche Grüße
Vinzenz
Hallo,
address 10.7.0.1
netmask 255.255.255.0Ich weiß nicht, ob diese "netmask" sehr glücklich gewählt ist. Wenn es Probleme gibt, würde ich es zunächst mit 255.0.0.0 versuchen.
ARGH! Mit 255.0.0.0 (also /8 in CIDR) wird Dennis sich DEFINITIV Probleme einhandeln! Denn 10.7.0.1/8 beschreibt das Netz 10.*.*.* - und damit AUCH das 10.6.*.*er-Netz!
Die Netzmaske ist so wie sie eingestellt ist absolut richtig für den Anwendungszweck und fast jede andere wäre vollkommen blödsinnig!
Bitte, wenn Du keine Ahnung hast (Du sagst ja selbst, "ich weiß nicht"), dann lass es bitte, solche unqualifizierten Kommentare zu hinterlassen! Das hält die Suche nach den eigentlichen Fehlern nur unnötig auf.
Viele Grüße,
Christian
hallo Christian,
Mit 255.0.0.0 (also /8 in CIDR) wird Dennis sich DEFINITIV Probleme einhandeln! Denn 10.7.0.1/8 beschreibt das Netz 10.*.*.* - und damit AUCH das 10.6.*.*er-Netz!
Genau darauf bezog sich das "ich weiß nicht". Ich habe mir bei vergleichbaren Aufgaben angewöhnt, das so aufzuteilen, daß das eine "Netz" beispielsweise 192.168.0 ist (mit 255.255.255.0) und das andere 10.0.0 (mit 255.0.0.0 als netmask).
Grüße aus Berlin
Christoph S.
Hi,
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
Deine Routing-Tabelle enthält zwei nicht-gealiaste Netzwerkeinträge für das Gerät eth0. Das verwirrt den Kernel.
Das Andere Netz (169.254.0.0/16) ist ein Netz, das beim sogenannten APIPA (Authomatic Private IP Assignement) verwendet wird. Ich vermute mal stark, bei Dir pfuscht noch irgendwie noch etwas rein, ich VERMUTE mal stark, das hängt mit dem »auto eth0« zusammen, aber ich kenne mich mit Debian nicht mehr wirklich aus, daher keine Ahnung.
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth
Der Eintrag sieht auch seltsam aus, zumal es das Netzwerkinterface 'eth' ohne Zahl gar nicht gibt...
Viele Grüße,
Christian
hallo Christian,
Das Andere Netz (169.254.0.0/16) ist ein Netz, das beim sogenannten APIPA (Authomatic Private IP Assignement) verwendet wird.
Diese Anmerkung geht vermutlich ziemlich unbeachtet unter - auch im Archiv. Man sollte das vielleicht mal etwas ausführen. Es hält sich ja hartnäckig trotz vieler Hinweise (auch hier im Forum bzw. in seinem Archiv; es gibt da ein paar sehr aufschlußreiche und ausführliche Beiträge von Sven Rautenberg) die so schön einfache Schematisierung nach A-, B- und C-Netzen. Bei den dafür meist bekannten Bereichen für "private IP-Adressen" wird zu häufig übersehen, daß die 169.254/16 ebenfalls eine "private" IP ist.
http://tools.ietf.org/html/rfc3927 beschreibt es eigentlich recht gut: "This document describes how a host may automatically configure an interface with an IPv4 address within the 169.254/16 prefix that is valid for communication with other devices connected to the same physical (or logical) link."
Was das allerdings bedeutet, wie damit umgegangen werden kann, und was es heißt, wenn 169.254/16 in einer Routing-Tabelle auftaucht, könnte eventuell mal erläutert werden - in einem posting hier, in einem Weblog-Beitrag oder in einem Fachartikel.
ich VERMUTE mal stark, das hängt mit dem »auto eth0« zusammen
Ich teile diese Vermutung, deshalb hatte ich ja bereits darauf hingewiesen.
aber ich kenne mich mit Debian nicht mehr wirklich aus, daher keine Ahnung.
Nun, dann kommt hier eine Retourkutsche: ich habe ebenfalls in https://forum.selfhtml.org/?t=163972&m=1068058 einen Hinweis geschrieben, bei dem ich mir ausdrücklich nicht sicher war. Du hast vehement widersprochen, was in der Sache vermutlich richtig war, im Ton allerdings arg daneben ging. Soll ich jetzt nun hier zurückpoltern und dir kategorisch gebieten: "Bitte, wenn Du keine Ahnung hast (Du sagst ja selbst, "ich ... habe keine Ahnung"), dann lass es bitte, solche unqualifizierten Kommentare zu hinterlassen!"?
Bisher galt doch in diesem Forum die - wenn auch niemals explizit formulierte - Übereinkunft: wenn du bei einem komplizierteren Sachverhalt einen Lösungsansatz nur vermutest, dir aber nicht sicher bist, dann schreib dazu, daß du nicht ganz sicher bist. Ist der Fragesteller kein absoluter Neuling mehr (und will auch nicht grade bloß wissen, wie man mit einem Link zwei Frames ändert), so wird er das immerhin als Idee honorieren und überprüfen.
Dennis ist kein Forumsneuling.
Mich hat der _Ton_ gewundert, den du in deiner Reaktion auf mein posting angeschlagen hast. Das ist deiner nicht würdig.
Und wie nun: soll ich dir empfehlen, dich künftig aus möglichen "*buntu-" und "Debian"-Threads fernzuhalten, weil du davon eh keine Ahnung hast - und mich künftig ebenso aus möglichen Threads zu Routing fernhalten? Das wäre doch so ziemlich das Dümmste, was wir uns gegenseitig empfehlen könnten.
Grüße aus Berlin
Christoph S.
ich VERMUTE mal stark, das hängt mit dem »auto eth0« zusammen
Ich teile diese Vermutung, deshalb hatte ich ja bereits darauf hingewiesen.
aber ich kenne mich mit Debian nicht mehr wirklich aus, daher keine Ahnung.
Nun, dann kommt hier eine Retourkutsche: [...]
Meine Vermutung basiert aber auf Fakten und logischen Schlüssen. Sie kann zwar falsch sein, sie ist jedoch sehr plausibel auf Grund des beschriebenen Sachverhalts (und Deinen Hinweis auf 'auto' habe ich übrigens auch nicht beanstandet). Ich weiß halt nicht, wie in Debian die Konfiguration aussieht, aber ich weiß zumindest, wie die Netzwerkkonfiguration unter Linux grundsätzlich funktioniert. Ich habe auf Grund der Angaben von Dennis gesehen "oh, da stimmt etwas nicht", dies als vermutetes Problem angenommen und dann an Hand der sonstigen Angaben eine plausible Ursache ausgemacht. Mag falsch sein, ist aber zumindest gut begründet.
Was Du jedoch gemacht hast: In einem Thread, bei dem es um Netzwerkprobleme geht, hast Du, obwohl Du offensichtlich nicht ausreichend Ahnung von grundlegenden Netzwerkbegriffen hast (und Netzmasken sind _absolutes_ Basiswissen), INS BLAUE HINEIN UNBEGRÜNDET einen SCHÄDLICHEN Hinweis gegeben. Und da mir dieses Verhalten bei Dir häufiger aufgefallen ist, ist meine Antwort etwas schroffer ausgefallen, als bei jemand anderem.
ok Christian,
Was Du jedoch gemacht hast: In einem Thread, bei dem es um Netzwerkprobleme geht, hast Du, obwohl Du offensichtlich nicht ausreichend Ahnung von grundlegenden Netzwerkbegriffen hast (und Netzmasken sind _absolutes_ Basiswissen), INS BLAUE HINEIN UNBEGRÜNDET einen SCHÄDLICHEN Hinweis gegeben. Und da mir dieses Verhalten bei Dir häufiger aufgefallen ist, ist meine Antwort etwas schroffer ausgefallen, als bei jemand anderem.
Die Konsequenz aus diesem Vorwurf ist, daß ich vermutlich darum bitten werde, alle knapp 15 000 postings mit meinem Namen aus dem Archiv zu löschen. Ich lasse es mir nochmal durch den Kopf gehen, es wird dann aber wohl auf euch zukommen.
Grüße aus Berlin
Christoph S.
Hallo nochmal,
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0Deine Routing-Tabelle enthält zwei nicht-gealiaste Netzwerkeinträge für das Gerät eth0. Das verwirrt den Kernel.
Oh, übrigens, was mir noch einfällt: Die Ausgabe von »/sbin/ifconfig eth0« wäre interessant zu wissen, walls das Entfernen von 'auto' Dein Problem nicht beseitigen sollte.
Viele Grüße,
Christian
Hi Christian,
Leider habe ich es im vorweihnachtlichen Stress nun nicht mehr geschafft bei dem Server vorbeizusehen, er steht nämlich bei uns in der Schule und nicht bei mir zu Hause ;-)
Ich werde also wohl erst nach den Feiertagen dazu kommen, deine Tipps wie auch die Tipps der anderen hier (Danke!) auszuprobieren. Falls dieser Thread bis dahin im Archiv ist, was ich befürchte, dann gibts halt noch mal einen neuen mit den Ergebnissen der von euch angeratenen Versuche. *g*
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0Deine Routing-Tabelle enthält zwei nicht-gealiaste Netzwerkeinträge für das Gerät eth0. Das verwirrt den Kernel.
Was bedeutet "nicht-gealiast" in diesem Zusammenhang? Du meinst, dass zwei Routen auf eth0 verweisen? Aber es verweisen doch auch zwei auf eth6...
Mich wundern viel mehr die beiden Zeilen, welche mit 169 beginnen:
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
Könnte in der Tat an dem auto liegen, ich werde es mal ohne auto eth(x) probieren. Reicht es eigentlich nach einem Ändern von /etc/network/interfaces ein /etc/init.d/networking restart
auszuführen, oder muss ich noch weitere Dinge beachten? Mir ist aufgefallen, dass die Änderungen in route -n
teilweise erst nach einem Neustart angezeigt werden.
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth
Der Eintrag sieht auch seltsam aus, zumal es das Netzwerkinterface 'eth' ohne Zahl gar nicht gibt...
Möglicherweise ein Copy&Paste-Fehler, aber ich werde auch das noch mal prüfen.
Viele Grüße,
~ Dennis.
Hi Dennis,
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0Deine Routing-Tabelle enthält zwei nicht-gealiaste Netzwerkeinträge für das Gerät eth0. Das verwirrt den Kernel.
Was bedeutet "nicht-gealiast" in diesem Zusammenhang? Du meinst, dass zwei Routen auf eth0 verweisen?
Normalerweise kann ein Interface nur eine IP-Adresse haben. Dementsprechend kann es auch erst einmal (!) nur ein Netzwerk geben, für die es eine Route ohne Gateway auf diesem Interface geben kann (irgendwelche Sonderkonfigurationsgedönse mal ausgenommen).
Allerdings: Du kannst einem physikalischem Interface durchaus mehrere IPs geben, indem Du ein "Alias" hinzufügst (das geht implizit), per Kommandozeile z.B. so:
ifconfig eth0:0 zusätzliche_ip netmask zusätzliche_netmask up
Damit erhält das physikalische Interface eine weitere IP, die halt intern zuästzlich vergeben ist.
Du hast hier jedoch so wie's aussieht nur eine IP und zwei Routing-Tabellen-Einträge auf das Interface OHNE Gateway (0.0.0.0 im Gateway-Feld heißt "kein Gateway"). Das ist schlecht (s.u.).
Aber es verweisen doch auch zwei auf eth6...
Nein, die zweite auf eth6 ist die Default-Route, die hier:
0.0.0.0 10.6.0.2 0.0.0.0 UG 100 0 0 eth6
Das Ding hat ein Gateway eingetragen (10.6.0.2).
Du musst folgendes Unterscheiden: Routen mit 0.0.0.0 als Gateway besagen "Das Ziel der Route ist DIREKT an dem Interface verfügbar". Diese werden auch idR. beim ifconfig ... up automatisch angelegt und man sollte da nie dran rumfummeln, außer man weiß, was man tut.
Routen mit irgend einer IP als Gateway eingetragen besagen "Das Ziel der Route ist erreichbar, wenn man die Pakete über den Rechner, der im Gateway-Eintrag steht, schickt". Die kann man auch (wenn es erforderlich ist) manuell anlegen.
Mich wundern viel mehr die beiden Zeilen, welche mit 169 beginnen:
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
Oh, das hatte ich übersehen, das könnte da auch noch mit hineinspielen (wobei multiple Routen zum gleichen Ziel wenn ich mich richtig erinnere lediglich dazu führen, dass die mit der niedirgeren Metrik verwendet wird, müsste ich aber noch mal nachschlagen, um ganz sicher zu sein). Allgemein würde ich Deine Netzwerkkonfiguration im Moment als zerschossen bezeichnen.
Reicht es eigentlich nach einem Ändern von /etc/network/interfaces ein
/etc/init.d/networking restart
auszuführen, oder muss ich noch weitere Dinge beachten?
Prinzipiell sollte das reichen (zumindest zu meinen Debian 3.0-Zeiten), da Deine Config jedoch zerschossen ist, kann das stop-Script unter Umständen die alten Regeln nicht richtig entfernen und es könnten Rest bleiben. Daher würde ich - bis Deine Netzwerkkonfiguration passt - lieber neustarten.
Viele Grüße,
Christian
Hi Christian,
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0Oh, das hatte ich übersehen, das könnte da auch noch mit hineinspielen (wobei multiple Routen zum gleichen Ziel wenn ich mich richtig erinnere lediglich dazu führen, dass die mit der niedirgeren Metrik verwendet wird, müsste ich aber noch mal nachschlagen, um ganz sicher zu sein). Allgemein würde ich Deine Netzwerkkonfiguration im Moment als zerschossen bezeichnen.
Ich hab mal man interfaces
dazu befragt:
Lines beginning with the word "auto" are used to identify the physical interfaces to be
brought up when ifup is run with the -a option. (This option is used by the system boot scripts.)
Physical interface names should follow the word "auto" on the same line. There can be multiple
"auto" stanzas.
Das scheint also mit der Auto-Konfiguration der IPs (wovon du sprachst) wenig zu tun zu haben, sondern mehr das System zu betreffen. Ich hatte das Gefühl, dass wenn ich "auto eth6" weglasse, z.B. der Eintrag für das Standardgateway (bei mir 10.6.0.2) in der Routing-Tabelle fehlt.
Übrigens steht das auto auch in der Default-Netzwerk-Konfiguration bei Hetzner ;-) Mein Root-Server hat es auch drin, ich gehe also mal davon aus, dass das nicht schadet *g*
Viele Grüße,
~ Dennis.
Hi Christian,
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth
Der Eintrag sieht auch seltsam aus, zumal es das Netzwerkinterface 'eth' ohne Zahl gar nicht gibt...
Sorry, das war in der Tat ein Copy&Past-Fehler:
root@Router:/etc/network# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.6.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth6
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth0
0.0.0.0 10.6.0.2 0.0.0.0 UG 100 0 0 eth6
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth1
root@Router:/etc/network#
Viele Grüße,
~ Dennis.
Hallo Dennis,
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth1
_DER_ Eintrag stört übrigenss auch GEWALTIG. Gut, die Metrik ist höher als die der Default-Route, daher ist er ERST EINMAL irrelevant, ALLERDINGS sollte man sich darauf nicht unbedingt verlassen. Wenn der Eintrag vorhanden ist und die Default-Route fehlt ODER der Eintrag vorhanden ist und eine niedrigere Metrik als die Default-Route besitzt, dann führt dies dazu, dass der Server keine Adressen mehr außerhalb lokaler Netze erreichen kann - und (!) dass im Falle des Fehlens einer Default-Route kein "Network unreachable" direkt zurückkommt, sondern man auf ein Timeout warten muss. Gut, da Du zufälligerweise eine niedrigere Metrik bei der Default-Route hast, tritt das ERST EINMAL nicht auf, aber der Eintrag sollte weg, solange der da ist (selbst wenn alles funktioniert), würde ich Deine Netzwerkkonfiguration immer noch als zerschossen bezeichnen.
Zudem: Woher dieser Eintrag kommt ist mir schleierhaft, eth1 ist nach Deinen Angaben gar nicht konfiguriert.
Ansonsten: Ausgabe von ifconfig wäre nicht schlecht und halt mal versuchen, das 'auto' loszuwerden (und dann sicherheitshalber neuzustarten).
Viele Grüße,
Christian
Hi Christian,
0.0.0.0 0.0.0.0 0.0.0.0 U 1000 0 0 eth1
_DER_ Eintrag stört übrigenss auch GEWALTIG. [...] Woher dieser Eintrag kommt ist mir schleierhaft, eth1 ist nach Deinen Angaben gar nicht konfiguriert.
Diesen Eintrag bin ich nun losgeworden ;-) Es scheint mir, als wäre diese Eintrag durch ein Paket namens "network-manager" verursacht worden. Dieses Paket, welches automatisch bei Ubuntu Desktop mitinstalliert wurde, hat mir schon von Anfang an nicht gefallen. Ich habe das Paket nun entfernt, offensichtlich ist es wirklich nur für Desktop-Einsatz gedacht, aber unser Router ist ja eher ein Server, auch wenn er (aus administrativen Gründen, an mir liegts nicht *g*) ein GNOME-Desktop-System drauf hat.
Nun ja, Reboot, nun sieht es so aus:
root@Router:/etc/network# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.6.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth6
10.7.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
169.254.0.0 0.0.0.0 255.255.0.0 U 1000 0 0 eth2
0.0.0.0 10.6.0.2 0.0.0.0 UG 100 0 0 eth6
Die Einträge sind alle korrekt nun, und siehe da, es funktioniert :-) Das "auto ethX" in der Konfiguration hab ich übrigens immer noch drin, aber da schreib ich gleich noch mal ein Posting in die richtige Stelle des Threads.
Du wirst sicherlich bemerkt habe, dass ich eth2 nun statt eth0 gewählt habe... Da muss ich mir wohl eine Unachtsamkeit eingestehen ;-) Ich habe nicht alle Netzwerkkarten durchprobiert, ich bin davon ausgegangen, dass nach dem Update von Kubuntu Ganz-Alte-Version auf Ubuntu 7.10 die Namen der Netzwerkarten immer noch die gleichen sind - dem ist wohl nicht so, was vorher eth0 war, ist nun eth2 *g*
Dazu aber direkt meine nächste Frage: Kann man diese Zuordnung ändern? Außerdem: Dieser Router hat sowohl 100MBit, wie auch 1GBit Netzwerkkarten. Wie kann ich erkenne, welche Karte welche ist? An der Ausgabe von ifconfig kann ich leider keinen Unterschied erkennen:
root@Router:/etc/network# ifconfig eth2
eth2 Link encap:Ethernet HWaddr 00:E0:81:55:1B:2B
inet addr:10.7.0.1 Bcast:10.7.0.255 Mask:255.255.255.0
inet6 addr: fe80::2e0:81ff:fe55:1b2b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:374 errors:0 dropped:0 overruns:0 frame:0
TX packets:35 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:149250 (145.7 KB) TX bytes:4920 (4.8 KB)
Base address:0x9000 Memory:f4020000-f4040000
root@Router:/etc/network# ifconfig eth6
eth6 Link encap:Ethernet HWaddr 00:60:08:0F:D9:98
inet addr:10.6.0.1 Bcast:10.6.0.255 Mask:255.255.255.0
inet6 addr: fe80::260:8ff:fe0f:d998/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1057 errors:0 dropped:0 overruns:0 frame:0
TX packets:791 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1244099 (1.1 MB) TX bytes:82904 (80.9 KB)
Interrupt:21 Base address:0xc400
Bei dem ersten handelt es sich auf jeden Fall um ein Gigabit, beim zweiten müsste es eigentlich ein 100MBit sein (das Netzwerk, welches Zugang zum Internet hat), ganz sicher bin ich mir aber grade nicht ;-)
Viele Grüße,
~ Dennis.
Hi,
Dazu aber direkt meine nächste Frage: Kann man diese Zuordnung ändern?
Eindeutiger Fall von Knoten im Kopf *g* Mir ist da eine, wenn auch recht koventionelle, Lösung eingefallen - einfach die LAN-Stecker am Server passend einstecken ;-) War zwar etwas aufwendig, weil der in einem Rack eingebaut ist, aber jetzt funktioniert es.
Viele Grüße,
~ Dennis.
Hallo,
Dazu aber direkt meine nächste Frage: Kann man diese Zuordnung ändern?
Ja, dazu müsstest Du Dich etwas in udev einlesen (sollte als Stichwort genug sein).
Du kannst damit die Interfaces sogar komplett umbenennen (nur Bindestrich drin ist doof, das geht zwar vom Kernel her, macht aber bei Scripten gerne Probleme), d.h. Du kannst Deine Netzwerkkarte auch "netzilein" nennen. ;-)
Allerdings: Mit udev kann man sich auch GEHÖRIG ins Knie schießen, also aufpassen. ;-)
Oder anders gesagt: Wenn's für Dich jetzt funktioniert, wäre es vielleicht ein blöder Zeitpunkt, mit udev rumzuspielen. ;-)
Außerdem: Dieser Router hat sowohl 100MBit, wie auch 1GBit Netzwerkkarten. Wie kann ich erkenne, welche Karte welche ist?
dmesg und lspci sollten zusammen Aufschluss darüber geben, was denn nun was ist. dmesg spuckt Dir die Zuordnung PCI-ID <-> Netzwerkinterface aus und lspci kann Dir zur PCI-ID weitere Infos zeigen (u.a. Hersteller- und Produktbeschreibung, wo eigentlich fast immer dabeisteht, wenn's Gigabit ist).
Viele Grüße,
Christian