7
Reihenfolge der Abarbeitung der Einträge in der Routing Table?
Hallo,
ich bin neu hier und das ist mein erster Beitrag.
Hab mir schon immer mal ein paar Anregungen geholt, nun komm ich aber nicht weiter.
Ich möchte gerne wissen, in welcher Reihenfolge bzw. nach welchen Kriterien Linux die Einträge in der Routing Table abarbeitet. Es kommt mir vor allem auf diese beiden einträge an:
192.168.156.0 * 255.255.255.0 U 0 0 0 eth0
192.168.156.0 * 255.255.255.0 U 0 0 0 eth1
Welcher wird warum als erstes verwendet?
Viele Grüße, Micha.
ich bin neu hier und das ist mein erster Beitrag.
Hab mir schon immer mal ein paar Anregungen geholt, nun komm ich aber nicht weiter.
Ich möchte gerne wissen, in welcher Reihenfolge bzw. nach welchen Kriterien Linux die Einträge in der Routing Table abarbeitet. Es kommt mir vor allem auf diese beiden einträge an:
192.168.156.0 * 255.255.255.0 U 0 0 0 eth0
192.168.156.0 * 255.255.255.0 U 0 0 0 eth1
Welcher wird warum als erstes verwendet?
Viele Grüße, Micha.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 15933
Url: https://administrator.de/contentid/15933
Ausgedruckt am: 22.11.2024 um 16:11 Uhr
7 Kommentare
Neuester Kommentar
@mloeffle
Hi,
deine Routingtabelle
192.168.156.0 * 255.255.255.0 U 0 0 0 eth0
192.168.156.0 * 255.255.255.0 U 0 0 0 eth1
ist etwas ungewöhnlich, weil hier Datenpakete über zwei versch.
Schnittstellen(eth0, eth1) in ein und dasselbe Ziel(192.168.156.0)
geschickt werden(sollen).
Ist das gewollt, oder liegt hier ein Mißverständnis(od. Konfig.-Fehler) vor?
Hattest du an etwas in der Art gedacht:
192.168.178.0 * 255.255.255.0 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth1
default 192.168.178.1 0.0.0.0 UG 0 0 0 eth0
--> localnet ist hier ein Alias für 192.168.179.0
Datenpakete an Adressen, die im LAN(localnet) nicht gefunden werden, gehen
automatisch(default) an Adressen über eth0 ins Ziel 192.168.178.0 bzw. zum Router
192.168.178.1 ins Internet und umgekehrt:
Datenpakete an Adressen, die im Internet(default) nicht gefunden werden, gehen
an Adressen über eth1 ins Ziel localnet(192.168.179.0).
Somit wären hier die Kriterien der Abarbeitung geklärt, während sie bei dir
ganz einfach undefiniert sind(m.M. nach).
Ich hoffe, ich hab´s einigermaßen plausibel und richtig erklärt.
Gruß
Günni
Hi,
deine Routingtabelle
192.168.156.0 * 255.255.255.0 U 0 0 0 eth0
192.168.156.0 * 255.255.255.0 U 0 0 0 eth1
ist etwas ungewöhnlich, weil hier Datenpakete über zwei versch.
Schnittstellen(eth0, eth1) in ein und dasselbe Ziel(192.168.156.0)
geschickt werden(sollen).
Ist das gewollt, oder liegt hier ein Mißverständnis(od. Konfig.-Fehler) vor?
Hattest du an etwas in der Art gedacht:
192.168.178.0 * 255.255.255.0 U 0 0 0 eth0
localnet * 255.255.255.0 U 0 0 0 eth1
default 192.168.178.1 0.0.0.0 UG 0 0 0 eth0
--> localnet ist hier ein Alias für 192.168.179.0
Datenpakete an Adressen, die im LAN(localnet) nicht gefunden werden, gehen
automatisch(default) an Adressen über eth0 ins Ziel 192.168.178.0 bzw. zum Router
192.168.178.1 ins Internet und umgekehrt:
Datenpakete an Adressen, die im Internet(default) nicht gefunden werden, gehen
an Adressen über eth1 ins Ziel localnet(192.168.179.0).
Somit wären hier die Kriterien der Abarbeitung geklärt, während sie bei dir
ganz einfach undefiniert sind(m.M. nach).
Ich hoffe, ich hab´s einigermaßen plausibel und richtig erklärt.
Gruß
Günni
Hi Günni,
ja, das ist so gewollt. Danke erst einmal. Denn auf dem Rechner laufen zwei Postfixe, die bei eingehender Mail über das eine, bei ausgehender Mail über das andere Interface kommunizieren. Das nur zur Erklärung.
Jetzt ist aber die Frage, wie so eine Routingtabelle ausgewertet wird. Soweit ich was gelesen habe, wird der Eintrag mit der größten Übereinstimmung (longest match) genommen. Wenn ich nun ins .156.x-Netz will, treffen beide Routing-Einträge zu. Welcher hat nun den longest match bzw. nach welchen Kriterien erfolgt die Auswahl eines Routing-Eintrags?
Micha
ja, das ist so gewollt. Danke erst einmal. Denn auf dem Rechner laufen zwei Postfixe, die bei eingehender Mail über das eine, bei ausgehender Mail über das andere Interface kommunizieren. Das nur zur Erklärung.
Jetzt ist aber die Frage, wie so eine Routingtabelle ausgewertet wird. Soweit ich was gelesen habe, wird der Eintrag mit der größten Übereinstimmung (longest match) genommen. Wenn ich nun ins .156.x-Netz will, treffen beide Routing-Einträge zu. Welcher hat nun den longest match bzw. nach welchen Kriterien erfolgt die Auswahl eines Routing-Eintrags?
Micha
Moin,
ich bin nicht so der Linuxer, aber unter Windows kann man die Priorität der Routen mit dem Anhängsel "Metric" einstellen.
Also ungefähr so: route add NETZ MASKE Metric=1
Je niedriger die Metric -Zahl, desto höher die Priorität.
Ich denke aber mal, dass das unter Linux nicht anders sein wird.
cu
Ralf
ich bin nicht so der Linuxer, aber unter Windows kann man die Priorität der Routen mit dem Anhängsel "Metric" einstellen.
Also ungefähr so: route add NETZ MASKE Metric=1
Je niedriger die Metric -Zahl, desto höher die Priorität.
Ich denke aber mal, dass das unter Linux nicht anders sein wird.
cu
Ralf
Hallo,
danke. Ja, da haben Sie Recht. Das ist natürlich ne Möglichkeit, um das Ganze zu steuern. Nur werden diese beiden Routing-Einträge automatisch erstellt. Deshalb bleibt also immer noch die Frage, wie verhält sich die Auswahl eines Einrags in genau diesem Fall.
danke. Ja, da haben Sie Recht. Das ist natürlich ne Möglichkeit, um das Ganze zu steuern. Nur werden diese beiden Routing-Einträge automatisch erstellt. Deshalb bleibt also immer noch die Frage, wie verhält sich die Auswahl eines Einrags in genau diesem Fall.
Ich würde sagen das sich nicht mit Sicherheit vorraussagen läßt welches Interface benutzt wird da die routing-tabelle falsch ist. Es macht keinen Sinn das eth1 + eth0 im selben Netz hängen, z.B. am selben Switch. Da ist wohl das System falsch verkabelt.
Was hast du da zusammengefrickelt?
Was hast du da zusammengefrickelt?
@mloeffle
Hi,
wie ich vermutet habe, ist die Reihenfolge der Abarbeitung der NIC´s in eurem Netz undefiniert bzw. laut folg. Zitat eines Artikels klar: die zweite NIC wird nie genutzt.
>Zitat Anfang:
Eine weitere NIC darf jetzt keine IP aus dem gleichen Netz haben. Probieren wir es einfach aus und sehen wir uns an, warum:
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
IPs, die durch unseren Host geroutet werden und in das 192.168.1.0 Netz gehen, werden von der ersten routing Zeile gematcht und führen über eth0. Die zweite Zeile kommt niemals an die Reihe und eth1 sendet nie, ausser wir fahren eth0 herunter.
Wie kommt es dann aber dazu, daß ein Host z.B. mit der IP 192.168.1.2 aus dem geswitchten Netz 192.168.1.0/24 bei einem ping auf 192.168.1.13 eine Antwort bekommt?
Nun, das liegt daran, daß der Kernel auf das ping reagiert und nicht die NIC. Dem Kernel ist ja die NIC mit der IP 192.168.1.13 bekannt, daher schickt er das reply zurück, das aufgrund der routing table über eth0 geht.
Deshalb ist in dieser Situation die Konfiguration der zweiten NIC auf ein anderes Subnetz zwingend erforderlich:
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Nun haben wir eine eindeutige Situation, und unser Host kann klar zwischen den beiden Netzen unterscheiden.
>Zitat Ende
Und wenn zwei Postfixe(ein- und ausgehende eMails) laufen, muß der für ausgehende eMails ja eine
Route zum Internet haben. Eine Route zurück ins eigene Netz macht ja irgendwie nicht soviel Sinn.
Gruß
Günni
Hi,
wie ich vermutet habe, ist die Reihenfolge der Abarbeitung der NIC´s in eurem Netz undefiniert bzw. laut folg. Zitat eines Artikels klar: die zweite NIC wird nie genutzt.
>Zitat Anfang:
Eine weitere NIC darf jetzt keine IP aus dem gleichen Netz haben. Probieren wir es einfach aus und sehen wir uns an, warum:
- ifconfig eth1 192.168.1.13 broadcast 192.168.1.255 netmask 255.255.255.0
- route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
IPs, die durch unseren Host geroutet werden und in das 192.168.1.0 Netz gehen, werden von der ersten routing Zeile gematcht und führen über eth0. Die zweite Zeile kommt niemals an die Reihe und eth1 sendet nie, ausser wir fahren eth0 herunter.
Wie kommt es dann aber dazu, daß ein Host z.B. mit der IP 192.168.1.2 aus dem geswitchten Netz 192.168.1.0/24 bei einem ping auf 192.168.1.13 eine Antwort bekommt?
Nun, das liegt daran, daß der Kernel auf das ping reagiert und nicht die NIC. Dem Kernel ist ja die NIC mit der IP 192.168.1.13 bekannt, daher schickt er das reply zurück, das aufgrund der routing table über eth0 geht.
Deshalb ist in dieser Situation die Konfiguration der zweiten NIC auf ein anderes Subnetz zwingend erforderlich:
- ifconfig eth0 192.168.1.12 broadcast 192.168.1.255 netmask 255.255.255.0
- ifconfig eth1 192.168.2.13 broadcast 192.168.2.255 netmask 255.255.255.0
- route -n
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
Nun haben wir eine eindeutige Situation, und unser Host kann klar zwischen den beiden Netzen unterscheiden.
>Zitat Ende
Und wenn zwei Postfixe(ein- und ausgehende eMails) laufen, muß der für ausgehende eMails ja eine
Route zum Internet haben. Eine Route zurück ins eigene Netz macht ja irgendwie nicht soviel Sinn.
Gruß
Günni
Hallo Günni,
danke für deine Mühe. Ich hatte nämlich mal bei nur gestecktem Kabel auf die zweite Karte einen Zugriff per SSH auf die zweite versucht, das ging nicht. Stecke ich das Kabel in die erste Karte, dann komme ich per SSH auf die zweite und die erste Karte einen Zugriff. Mal angenommen, alle NIC sind im gleichen Netz, auch die, von der der SSH-Zugriff ausging.
Micha
danke für deine Mühe. Ich hatte nämlich mal bei nur gestecktem Kabel auf die zweite Karte einen Zugriff per SSH auf die zweite versucht, das ging nicht. Stecke ich das Kabel in die erste Karte, dann komme ich per SSH auf die zweite und die erste Karte einen Zugriff. Mal angenommen, alle NIC sind im gleichen Netz, auch die, von der der SSH-Zugriff ausging.
Micha
