[HaBo]

bitmuncher

Anzeige

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:

Die Route für eth1 wird mittels Skript gesetzt

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:

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.

__________________

Chromatin

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?

__________________
Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

Habo Blog - http://blog.hackerboard.de/

bitmuncher

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:
'route -n' auf Server2:
Auf Server 1 funktioniert es mit den oben gezeigten Routing-Regeln. Bei Server 2 funktioniert es nicht.

__________________

Chromatin

Ich verstehe nicht, warum du der Kiste sich selbst als Destination fuer eine Route vorgibst.

__________________
Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

Habo Blog - http://blog.hackerboard.de/

bitmuncher

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?

__________________

sw33tlull4by

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.

Chromatin

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.

__________________
Wenn ein Gesetz nicht gerecht ist, dann geht die Gerechtigkeit vor dem Gesetz!

Habo Blog - http://blog.hackerboard.de/

bitmuncher

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.

__________________

gelöscht

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

Serow

Du sagst Server 1 hat die IP 192.168.2.2. Und lauf deinem posting ne Route auf sich selbst über 192.168.0.1?

bitmuncher

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

__________________

Serow

sry 192.168.0.2

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?

bitmuncher

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.

__________________

Serow

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

bitmuncher

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.

__________________