Zweite Route will nicht

bitmuncher

bitmuncher

Senior-Nerd
Situation ist folgende...

2 Server, beide identisch eingerichtet (Debian Lenny). einziger Unterschied liegt bei den IPs. Beide Server haben eine externe IP, mit der sie am Switch hängen (eth0) und eine LAN-IP, mit der sie an einem Loadbalancer hängen (eth1). Auf Server1 stellt das auch kein Problem dar. Auf beiden Servern sieht die interfaces-Datei so aus:

Code: 
allow-hotplug eth0
auto eth0
iface eth0 inet static
        address 81.xx.xx.xx
        netmask 255.255.255.224
        gateway 81.xx.xx.xx

iface eth1 inet static
        address 192.168.0.2
        netmask 255.255.255.0

Die Route für eth1 wird mittels Skript gesetzt

Code: 
route add -host 192.168.0.2 gw 192.168.0.1

Server2 hat als LAN-IP die 192.168.0.3, ist absolut identisch eingerichtet, aber die Route scheint keinen Effekt zu haben. Es geht aber, wenn ich einen Default-Gateway für eth1 setze, dann ist die Kiste aber nicht mehr direkt über eth0 erreichbar.

'route -n' gibt auf beiden Servern folgendes aus:

Code: 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.2     192.168.0.1     255.255.255.255 UGH   0      0        0 eth1
81.xx.xx.xx     0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         81.xx.xx.xx     0.0.0.0         UG    0      0        0 eth0

Der einzige Unterschied liegt in Regel 1, wo bei Server2 die 192.168.0.3 als Destination drin steht.

Warum funktioniert also die Routing-Regel auf Server1, aber nicht auf Server2? Was übersehe ich hier? Bin für jede Idee dankbar.
 
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.2 192.168.0.1 255.255.255.255 UGH 0 0 0 eth1
81.xx.xx.xx 0.0.0.0 255.255.255.224 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 81.xx.xx.xx 0.0.0.0 UG 0 0 0 eth0



Der einzige Unterschied liegt in Regel 1, wo bei Server2 die 192.168.0.3 als Destination drin steht.

Warum funktioniert also die Routing-Regel auf Server1, aber nicht auf Server2? Was übersehe ich hier? Bin für jede Idee dankbar.
Zum Vergrößern anklicken....

Server 2 hat die IP 192.168.0.3?
Und 192.168.0.3 steht ebenfalls als destination in deiner Ausgabe?
Sollte da nicht das Ziel drinstehe, wo du mit der Kiste hinwillst (Der LB nehme ich an)

Teste es mal mit einer netz-route.


Ich meine:
Server 1 : address 192.168.0.2
route nach ??? ueber 192.168.0.1

Server 2 : address 192.168.0.3
route nach ??? ueber 192.168.0.1

Also wohin wollen die eigentlich? :)
 
Loadbalancer
IP: 192.168.0.1

Server1
IP: 192.168.0.2
Routet alle Anfrage auf das Interface/diese IP über den Gateway 192.168.0.1.

Server2
IP: 192.168.0.3
Routet (bzw. soll routen) alle Anfrage auf das Interface/diese IP über den Gateway 192.168.0.1.

'route -n' auf Server1:
Code: 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.2     192.168.0.1     255.255.255.255 UGH   0      0        0 eth1
81.xx.xx.xx     0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         81.xx.xx.xx     0.0.0.0         UG    0      0        0 eth0

'route -n' auf Server2:
Code: 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.3     192.168.0.1     255.255.255.255 UGH   0      0        0 eth1
81.xx.xx.xx     0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         81.xx.xx.xx     0.0.0.0         UG    0      0        0 eth0

Auf Server 1 funktioniert es mit den oben gezeigten Routing-Regeln. Bei Server 2 funktioniert es nicht.
 
Weil alle Anfragen, die dieses Ziel haben über den GW 192.168.0.1 beantwortet werden sollen. Wie sollte es denn sonst gehen? Ist ja kein Router und diese Route soll ja nur für die eigene IP des Servers gelten.

Wie bereits gesagt, funktioniert es ja auch auf Server1, aber eben nicht bei Server2. Die Frage ist also nicht... warum diese oder jene Destination, sondern warum funktioniert die Routing-Regel auf Server1, nicht aber auf Server2?
 
Mich wundert das da ueberhaupt was durchkommt, denn du hast
einmal 81.xxx als destination und 0.0.0.0 als gateway und einmal sagst du
0.0.0.0 ist destination und 81.x.x.x ist gateway und beidest auf eth0.
Funktionieren die Server denn auch wenn du einen von beiden abschaltest?
mfg

sw33t

//edit
was auch noch auffaellt ist das du anfragen auf 192.168.0.x nach 192.168.0.1 umleitest
Dann aber alle 192.168.0.xxx auf die Defaultroute mappst und diese dann ueber eth0 ins Internet schickst.
Und wenn duZeile 3 weglaesst kann man intern nicht mehr auf die Server zugreifen.
 
Weil alle Anfragen, die dieses Ziel haben über den GW 192.168.0.1 beantwortet werden sollen. Wie sollte es denn sonst gehen? Ist ja kein Router und diese Route soll ja nur für die eigene IP des Servers gelten.
Zum Vergrößern anklicken....

Vermutlich muss man das Gesamtbild kennen um das nicht total seltsam zu finden :)

Hast du mal eine netz route probiert?
Wenn nicht, probiers mal. Weil irgendwie kommt mir diese Routingkonstellation falsch vor.
 
Also, ich versuch nochmal das Gesamtbild zusammenzufassen.

Hardware:
1x Loadbalancer
- externe Interfaces für die Cluster 81.xx.xx.xx
- internes Interface: 192.168.0.1 (daran hängen die Webserver)
2x Server (baugleich und identisch eingerichtet) mit jeweils 2 Netzwerk-Interfaces
- externe Interfaces: 81.xx.xx.xx
- internes Interface zum Loadbalancer von Server1: 192.168.0.2
- internes Interface zum Loadbalancer von Server2: 192.168.0.3

Über die externen Interfaces hängen alle Geräte über ein Switch am Backbone.

Beim Netzwerk-Start wird nur eth0 mit der externen IP initialisiert, so dass ich über die externe IP auf die Server zugreifen kann. eth1 fahre ich mittels 'ifup eth1' händisch hoch. Da für eth1 in der interfaces-Datei kein Gateway steht, bekommt es natürlich erstmal den Default-Gateway von eth0 zugewiesen. Trage ich allerdings für eth1 in der interfaces einen Gateway ein, wird (logischerweise) der Default-GW von eth0 überschrieben, da im System nur ein Default-Gateway existieren kann und in der Interfaces meines Wissens nach nur der Default-Gateway eingetragen werden kann. Wüsste zumindest nicht wie ich dort definieren könnte, dass ein Gateway ausschliesslich für ein spezifisches Interface genutzt werden soll.

Starte ich also eth1, hat es den Default-Gateway, den ich dann mittels 'route add -host 192.168.0.x gw 192.168.0.1' überschreibe. Ich setze also für das Host 192.168.0.x den Gateway 192.168.0.1 (den Loadbalancer). Routing-Tabellen werden sequentiall abgearbeitet und die erste Route, die matcht, wird genommen. Da neue Routen immer am Anfang der Tabelle eingefügt werden (zumindest am Anfang der Hosts- bzw. Netzwerk-Abschnitte innerhalb der Routing-Tabelle), matcht diese händisch festgelegte Routing-Regel zuerst. So zumindest mein Verständnis von der Sache. Auf Server1 funktioniert diese Vorgehensweise auch mit 'route add -host 192.168.0.2 gw 192.168.0.1'. Auf Server2 scheint 'route add -host 192.168.0.3 gw 192.168.0.1' aber keinen Effekt zu haben.

Eine Route für das gesamte Subnetz 192.168.0.0/24 hab ich auch bereits probiert.
 
Hallo bitmuncher,

mich würde mal interessieren was das Tracen dir ausgibt, wenn Du einen Trace von Server2 zum Gateway machst (und andersrum).

Da wäre ja ein Ansatzpunkt, wo der Fehler liegen wird (d.h. an welcher Schnittstelle).

Das Routen kannst Du ja sehr gut mit einem Trace verfolgen, wie Dir das sicherlich bekannt ist und mich würde dabei interessieren bis wohin Du überhaupt kommst mit Deiner eingetragenen statischen Route.

Grüße

Zephyros
 
Original von Zephyros
Hallo bitmuncher,

mich würde mal interessieren was das Tracen dir ausgibt, wenn Du einen Trace von Server2 zum Gateway machst (und andersrum).
Zum Vergrößern anklicken....

Code: 
BLN002:~# traceroute 192.168.0.1
traceroute to 192.168.0.1 (192.168.0.1), 30 hops max, 40 byte packets
 1  localhost (192.168.0.1)  2.659 ms  2.661 ms  2.657 ms

Code: 
root@balancer# traceroute 192.168.0.3
traceroute to 192.168.0.3 (192.168.0.3), 64 hops max, 44 byte packets
 1  localhost (192.168.0.3)  0.413 ms  0.412 ms  0.481 ms

@Serow: Keine Ahnung wo du was von 192.168.2.2 liest.
 
sry 192.168.0.2

Server1
IP: 192.168.0.2
Routet alle Anfrage auf das Interface/diese IP über den Gateway 192.168.0.1.
Zum Vergrößern anklicken....

'route -n' auf Server1:
Code: 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.0.2     192.168.0.1     255.255.255.255 UGH   0      0        0 eth1
81.xx.xx.xx     0.0.0.0         255.255.255.224 U     0      0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
0.0.0.0         81.xx.xx.xx     0.0.0.0         UG    0      0        0 eth0
Zum Vergrößern anklicken....

Wenn ich jetzt nicht gerade total aufm Schlauch stehe, sagt die erste Route doch dass er sich selbst über 192.168.0.1 erreicht oder? Sollte das er nicht eher Server 2 über 192.168.0.1 erreichen?
 
Die erste Regel besagt, dass sämtlicher Traffic für das Host 192.168.0.2 über den Gateway 192.168.0.1 (also den Loadbalancer) gehen soll.
 
Ja genau - aber die Regel ist ja auch 192.168.0.2 gesetzt. Das würde doch heissen, dass 192.168.0.2 Packete an 192.168.0.2 über 192.168.0.1 routet. Wenn das für euch Sinn ergibt, dann vergesst mein gelaber :D
 
Ist schon richtig und es ist auch so geplant, da auch innerhalb des Clusters ein Balancing stattfinden muss und er z.B. Requests an einen lokalen MySQL-API-Node senden muss, der via Balancer auf die Storage-Nodes verteilt wird. Daher muss sämtlicher Traffic für eth1 über 192.168.0.l laufen. Ausserdem muss der Webserver ja auch über diesen die Antworten rausschicken.
 
Im Prinzip sagt es, vielleicht einfacher ausgedrückt, aus, dass der eingehende und ausgehende Verkehr über den Gateway zum Server direkt geleitet wird und nicht über Umwege.

Frage an bitmuncher:

1. Wenn Du den Gateway, wie im 1. Post geschrieben, auf eth1 legst, dort die Metrik auf z.B. 5 stellst und die Metrik bei eth0 auf 0 oder 1 stellst, was passiert denn dann ?
Bekanntlich wird immer der kürzere Weg gesucht, wenn der aber blockiert wird o.ä. dann wird der andere Weg genommen.

2. Inwieweit kannst Du an dem besagten Server ein wenig experimentieren ? Ich Frage deshalb, weil mich mal interessieren würde was passiert wenn Du die beiden Ethernet - Schnittstellen "überbrückst"

3. Wenn Du mal von Server 2 auf Server 1 tracerst, was passiert denn dann ?

Grüße

Zephyros
 
@Zephyros: Rumexperimentieren kann ich schon. Hab nur wenig Lust schon wieder in's Rechenzentrum zu fahren, sonst verpass ich Simpsons. ;) :D Also sollte ein Interface irgendwie immer erreichbar bleiben während ich rumexperimentiere, damit ich via SSH arbeiten kann. Dein Hinweis 3 war aber schonmal gut, denn dort sieht es seltsamerweise so aus:

Code: 
BLN002:~# traceroute 192.168.0.2
traceroute to 192.168.0.2 (192.168.0.2), 30 hops max, 40 byte packets
 1  localhost (192.168.0.2)  0.526 ms  0.522 ms  0.518 ms

Als würde er sich selbst unter dieser IP "kennen". ?( Ein Ping gibt ein "Destination host unreachable", und geht scheinbar auch über das externe Interface anstatt über das interne:

Code: 
BLN002:~# ping 192.16.0.2
PING 192.16.0.2 (192.16.0.2) 56(84) bytes of data.
From 83.137.96.5 icmp_seq=1 Destination Host Unreachable
 
Immer diese Simpsons :D

Ok, das mit der Überbrückung sparen wir uns dann mal, da nicht sicher ist das Du per SSH auf eine der beiden Schnittstellen dann noch zugreifen kannst.

Als heißt es für Dich, dass Du Dir wohl oder übel nochmal Deine Konfiguration der Schnittstelle anschauen musst, irgendwo wird ein Fehlerteufel sich vermutlich eingeschlichen haben, oder aber der Switch oder die IPTables o.ä.

Ich glaube ich kann Dir da auch erstmal nicht weiter helfen, da doch bei so einer Sache eine Ferndiagnose recht schwierig werden wird. Aber laut Deinem neuen Trace und Deinem Pingen, scheint irgendwas in der Konfiguration zwischen dem Server 2 und dem Netzwerk nicht korrekt zu laufen. Identische Konfiguration hin oder her, Fehlerteufel schleichen sich immer mal ein, wenn das alles immer Perfekt sein würde hätten wir als Administratoren wenig bis gar nichts zu tun :D

So leid es mir tut, aber Du wirst wohl über eine Überprüfung nicht herum kommen, dazu stehen Dir aber sicherlich einige Netzwerktools (Diagnose, Paketverfolgung, etc.) zur Verfügung.

Grüße und viel Glück, bin gespannt was da noch so kommt :)

Zephyros
 
So, habe jetzt nochmal ein paar Testcluster angelegt.

Cluster1 enthält nur Server1 mit SSH-Port-Freigabe. Funktioniert.
Cluster2 enthält nur Server2 mit SSH-Port-Freigabe. Funktioniert.
Cluster3 enthält beide Server als Webserver. Funktioniert nicht bzw. wird im Endeffekt immer auf Server1 geschaltet. Laut Logs bekomme ich von Server2 ein Timeout.
Cluster4 enthält nur Server2 als Webserver. Funktioniert nicht (reset by peer).

Lokaler Aufruf des Webservers mittels 'links http://192.168.0.3' funktioniert aber. Via Telnet komme ich auf vom Loadbalancer auf den Webserver von Server2. Also muss ich scheinbar wohl doch noch weiter in der Balancer-Konfiguration schauen wo es hängt.

Danke erstmal an alle soweit.

Edit: Danke an alle. Jetzt läuft es. Problem war tatsächlich eine Einstellung im Balancer. Scheinbar muss ich für Webserver das Spoof-Flag ausmachen, das für SSH aber notwendig ist. Dieses sorgt dafür, dass Verbindungen so durchgereicht werden, dass sie scheinbar direkt vom Client kommen und die Webserver nicht die IP des Balancers zu sehen bekommen. Dadurch wurden die Antworten über das externe Interface rausgereicht anstatt über das interne.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben