Hallo !
Ich habe 2 Server (Windows Server 2003, Active Directory) mit je 2 Netzwerkkarten (1x 100Mbit, 1x 1000MBit). Diese hängen per 100er Karte am internen Netz und bekommen dafür auch eine offizielle IP zugewiesen (Änderungen im DNS sind nicht möglich). Nun sollen diese Rechner per Crossover-Kabel an den 1000er Interfaces verbunden werden. Wie ist das Routing einzurichten, damit Pakete zum jeweils anderen Rechner über die 1000er Crossover-Verbindung gesendet werden ?
Alexander
Hallo !
Hi,
Ich habe 2 Server (Windows Server 2003, Active Directory) mit
Ich kenn ich mit Windows eher leidlich aus. Routing ist zum Glueck plattformunabhaengig.
je 2 Netzwerkkarten (1x 100Mbit, 1x 1000MBit). Diese hängen
per 100er Karte am internen Netz und bekommen dafür auch eine
offizielle IP zugewiesen (Änderungen im DNS sind nicht
möglich). Nun sollen diese Rechner per Crossover-Kabel an den
1000er Interfaces verbunden werden. Wie ist das Routing
einzurichten, damit Pakete zum jeweils anderen Rechner über
die 1000er Crossover-Verbindung gesendet werden ?
Fuege einfach eine neue route auf einen host (den jeweils anderen Rechner) hinzu und sage, dass dieser ueber das 1GB-interface zu erreichen ist. Im Linux waere das mit sowas wie
# route add -host 10.0.0.1 dev eth1
zu erreichen,auf dem anderen Rechner genauso, jeweils mit gegenueberliegender IP#. Im Windows geht das sicher aehnlich. Es sollte auch egal sein, ob Du die IP# vom 1GB-interface oder die vom kleinen nimmst. Das dicke interface braucht IMHO nicht mal eine IP#, es sollte reichen, wenn es up ist (Propier das mal, interessiert mich. Ansonsten nimm da irgendwelche RFC1918-Adressen.)
HTH,
Gruss vom Frank.
Hi,
Ich habe 2 Server (Windows Server 2003, Active Directory) mit
je 2 Netzwerkkarten (1x 100Mbit, 1x 1000MBit). Diese hängen
per 100er Karte am internen Netz und bekommen dafür auch eine
offizielle IP zugewiesen (Änderungen im DNS sind nicht
möglich). Nun sollen diese Rechner per Crossover-Kabel an den
1000er Interfaces verbunden werden. Wie ist das Routing
einzurichten, damit Pakete zum jeweils anderen Rechner über
die 1000er Crossover-Verbindung gesendet werden ?
Eigentlich sollte da gar nichts einzurichten sein. Immerhin sind die beiden PCs direkt verbunden, wofür also routen? Gib den beiden einfach je eine private IP-Adresse aus einem Netz, das sonst nicht benutzt wird, und fertig. Um die DNS Einträge, die ja die offiziellen IPs zurückgeben, zu überschreiben, fügst Du den jeweils anderen Rechner in die hosts-Datei ein, die wird vor dem DNS-Server abgefragt.
Gruß,
Malte.
das sonst nicht benutzt wird, und fertig. Um die DNS Einträge,
die ja die offiziellen IPs zurückgeben, zu überschreiben,
fügst Du den jeweils anderen Rechner in die hosts-Datei ein,
die wird vor dem DNS-Server abgefragt.
Das war der Hinweis, der mir gefehlt hat. Nach den Einträgen in die hosts Datei läuft es…
Danke,
Alexander
Hi,
Das dicke interface braucht IMHO
nicht mal eine IP#, es sollte reichen, wenn es up ist
Wie willst Du denn IP fahren ohne IP-Adresse?
Das scheitert doch schon daran, daß das Emüfängerinterface gar nicht weiß, daß die Daten für diese Maschine bestimmt sind. Oder hab ich da was falsch verstanden?
Gruß,
Malte.
Hi,
Tach,
nach meiner Erfahrung kann man mit routing einige kranke Sachen machen. Das da wuerde ich dazu zaehlen.
Das dicke interface braucht IMHO
nicht mal eine IP#, es sollte reichen, wenn es up istWie willst Du denn IP fahren ohne IP-Adresse?
Er hat ja eine. Auf dem anderen interface. AFAICS hat der OP folgendes setup:
-----+-----------+----- LAN (192.168.0.0/24)
| |
,---+---. ,---+---. 100MBit/s (eth0)
| Box 1 \*===\* Box 2 | 1GBit/s (eth1)
`-------' `-------'
Die 100er seien 192.168.0.1 und .2, die GBits meinethalben irgendwo im 10.0.0.0. Jetzt trage ich auf der Box1 eine route via GBit fuer die .0.2 ein und sage, dass die von der IP# .0.1 kommen sollen (ich gestehe, letzteres nicht erwaehnt zu haben), auf Box2 vice versa.
root@box1 [~] # ip route add 192.168.0.2 dev eth1 src 192.168.0.1
root@box2 [~] # ip route add 192.168.0.1 dev eth1 src 192.168.0.2
Schickt eine Box jetzt Pakete zur IP# des 100er der anderen wird das via GBit geroutet. Da sie als source IP# die IP# des 100ers hat, gehen die Antworten auch nicht an das GBit-interface, sondern zurueck zum 100er, voila, IP ohne IP#s (wenn man so will).
Ich weisz nicht, ob es wirklich klappt, dass die interfaces ohne IP# rumlaufen, aber gebraucht werden sie nicht mehr. Ich weisz auch nicht, ob das so sinnvoll ist.
Gruss vom Frank.
Hi,
nach meiner Erfahrung kann man mit routing einige kranke
Sachen machen. Das da wuerde ich dazu zaehlen.
Stimmt, krank wäre es 
root@box1 [~] # ip route
> add 192.168.0.2 dev eth1 src 192.168.0.1
> root@box2 [~] # ip route add 192.168.0.1 dev eth1 src
> 192.168.0.2
Schickt eine Box jetzt Pakete zur IP# des
100er der anderen wird das via GBit geroutet. Da sie als
source IP# die IP# des 100ers hat, gehen die Antworten auch
nicht an das GBit-interface, sondern zurueck zum 100er, voila,
IP ohne IP#s (wenn man so will).
Was macht denn ein Netzwerktreiber, der ein IP-Paket in einem Ethernetframe bekommt? Er schaut nach, ob das Paket/der Frame für ihn bestimmt ist. Das ist in diesem Fall nicht gegeben, und der Frame müsste schon auf Ethernet-Ebene verworfen werden.
Warum ist das nicht gegeben? Irgendwoher muß der Frame ja seine Ziel-MAC bekommen. Normalerweise tut er das via arp, richtig? Was gibt arp aber denn in diesem Fall zurück? Ich finde das gerade etwas verwirrend, aber ich kann mir keinen Weg vorstellen, auf dem die MAC des anderen GBit-ifs herauskommt.
Ich weisz auch nicht, ob das so sinnvoll ist.
In Anbetracht der Tatsache, daß es einen einfacheren Weg gibt, glaube ich da nicht dran
Gruß,
Malte.
PS: Was ist denn gezz mit meinem Beck’s? Mein Mailserver ist momentan kaputt (Danke, Hetzner - Festplattencrash, Maschine damit quasi hin). [email protected] geht noch.
Schickt eine Box jetzt Pakete zur IP# des
100er der anderen wird das via GBit geroutet. Da sie als
source IP# die IP# des 100ers hat, gehen die Antworten auch
nicht an das GBit-interface, sondern zurueck zum 100er, voila,
IP ohne IP#s (wenn man so will).Was macht denn ein Netzwerktreiber, der ein IP-Paket in einem
Ethernetframe bekommt? Er schaut nach, ob das Paket/der Frame
für ihn bestimmt ist. Das ist in diesem Fall nicht gegeben,
und der Frame müsste schon auf Ethernet-Ebene verworfen
werden.
Einspruch! Der Kartentreiber schert sich um IP einen feuchten.
Warum ist das nicht gegeben? Irgendwoher muß der Frame ja
seine Ziel-MAC bekommen. Normalerweise tut er das via arp,
richtig? Was gibt arp aber denn in diesem Fall zurück?
Box 1 macht einen arp broadcast who has 192.168.0.2 tell 192.168.0.1. Da es ein broadcast ist fischt der Treiber auf Box 2 es aus dem Kabel und fragt beim darueberliegenden IPstack nach ‚Sind wir zufaellig 192.168.0.2?‘ Der stack bestaetigt, dasz er die IP# hat (dasz das auf einem anderen if ist, stoert nicht, der stack hat (dank ISO/OSI) eh keine Ahnung von interfaces). Daraufhin blubbert Treiber ins Kabel reply 192.168.0.2 is-at $MAC. Als MAC gibt er dabei seine eigene an.
Das sieht man auch in der arp table der Rechner: mit den IP#s der 100er sind die MACs der GBits verbunden.
Ich finde das gerade etwas verwirrend, […]
Deshalb heiszt das routing. („Wenn man schon nicht ueberzeugen kann sollte man wenigstens verwirren koennen.“ Qelle vergessen)
In Anbetracht der Tatsache, daß es einen einfacheren Weg gibt,
glaube ich da nicht dran
Naja, hack value. (Manchmal braucht man sowas auch wirklich.) Und ich find den Weg gar nicht so schwer.
PS: Was ist denn gezz mit meinem Beck’s? Mein Mailserver ist
momentan kaputt (Danke, Hetzner - Festplattencrash, Maschine
damit quasi hin). [email protected] geht noch.
Ich forwarde nochmal da hin,
Gruss vom Frank.
Hallo,
Mein Mailserver ist
momentan kaputt (Danke, Hetzner - Festplattencrash, Maschine
damit quasi hin). [email protected] geht noch.
Dafür hast Du ja wenigstens einen Backup-MX-Server 
Gruß,
Sebastian
Hallo,
Mein Mailserver ist
momentan kaputt (Danke, Hetzner - Festplattencrash, Maschine
damit quasi hin). [email protected] geht noch.Dafür hast Du ja wenigstens einen Backup-MX-Server
Stimmt. Wie lange kümmert der sich eigentlich um Nachrichten? Ich meine, wirklich halten tut er sie ja nicht, oder?
Gruß,
Malte.
Hi,
Einspruch! Der Kartentreiber schert sich um IP einen
feuchten.
Ja, aber um Ethernet umso mehr.
Warum ist das nicht gegeben? Irgendwoher muß der Frame ja
seine Ziel-MAC bekommen. Normalerweise tut er das via arp,
richtig? Was gibt arp aber denn in diesem Fall zurück?Box 1 macht einen arp broadcast who has 192.168.0.2 tell
192.168.0.1 . Da es ein broadcast ist fischt der Treiber
auf Box 2 es aus dem Kabel und fragt beim darueberliegenden
IPstack nach ‚Sind wir zufaellig 192.168.0.2?‘ Der stack
bestaetigt, dasz er die IP# hat (dasz das auf einem anderen if
ist, stoert nicht, der stack hat (dank ISO/OSI) eh keine
Ahnung von interfaces). Daraufhin blubbert Treiber ins Kabel
reply 192.168.0.2 is-at $MAC. Als MAC gibt er dabei
seine eigene an.
Seine eigene, die auf dem GBit-if liegt? Kaum zu glauben. Aber wahr? Dirty.
Das sieht man auch in der arp table der Rechner: mit den IP#s
der 100er sind die MACs der GBits verbunden.Ich finde das gerade etwas verwirrend, […]
Deshalb heiszt das routing. („Wenn man schon nicht
ueberzeugen kann sollte man wenigstens verwirren koennen.“
Qelle vergessen)In Anbetracht der Tatsache, daß es einen einfacheren Weg gibt,
glaube ich da nicht dranNaja, hack value. (Manchmal braucht man sowas auch wirklich.)
Und ich find den Weg gar nicht so schwer.
Nein, wirklich schwer ist das nicht, in der Tat. Ich kann noch nicht wirklich glauben, daß das funktioniert und standardkonform ist. Vielleicht hab ich ja mal die Möglichkeit, das auszuprobieren.
Gruß,
Malte.
[off-topic] Backup-MX und Haltezeit
Hallo,
Dafür hast Du ja wenigstens einen Backup-MX-Server
Stimmt. Wie lange kümmert der sich eigentlich um Nachrichten?
[niehaus@mirage] cat /var/qmail/control/queuelifetime
1000000
Das ist dann in Sekunden. [siehe auch: http://www.lifewithqmail.org/lwq.html#config-files ]
Ich meine, wirklich halten tut er sie ja nicht, oder?
Nein, er hat keine Sicherheits_kopie_. Wenn der Hauptserver down ist, werden sie dort entgegengenommen und bleiben dort liegen. Man kann dann zum Beisiel einen anderen Server nehmen, den man als Zielhost nimmt (wenn der alte so kaputt ist, daß man ihn in absehbarer Zeit nicht mehr in Gang bekommt) oder die Haltezeit so lange erhöhen, bis die Kiste wieder läuft.
mirage# grep -c crowdserver /var/log/qmail/@\*
/var/log/qmail/@4000000040c012bc381c95fc.s:2
/var/log/qmail/@4000000040c0278e30bbc2ec.s:0
/var/log/qmail/@4000000040c03ff929034674.s:0
/var/log/qmail/@4000000040c05a0608f7a974.s:0
/var/log/qmail/@4000000040c06f383465b434.s:0
/var/log/qmail/@4000000040c088652d8d75fc.s:0
/var/log/qmail/@4000000040c09de32c4e5a94.s:0
/var/log/qmail/@4000000040c0b4191e7e6774.s:0
/var/log/qmail/@4000000040c0ccf108769294.s:0
mirage#
Naja, hin und wieder kümmert er sich ja um was …
HTH & Gruß,
Sebastian
Hallo,
Dafür hast Du ja wenigstens einen Backup-MX-Server
Stimmt. Wie lange kümmert der sich eigentlich um Nachrichten?
Naja, hin und wieder kümmert er sich ja um was …
Ups. Ich hab da was verwexelt… Der crowdserver ist up and running. Down ist alliednetworks.de. Vor allem SO down… Damit hatte ich nicht gerechnet. Wir haben zwar Backups von den Nutzdaten (Mail & Webcontent), aber das Ding muß wohl komplett neu aufgesetzt werden. Mal sehen, ob wir das am Wochenende schaffen. Ich sehe wenig Schlaf auf mich zukommen… Und einen zweiten Server als Mirror sowie einen Providerwechsel.
Gruß,
Malte.
Hallo,
Dafür hast Du ja wenigstens einen Backup-MX-Server
Stimmt. Wie lange kümmert der sich eigentlich um Nachrichten?
Naja, hin und wieder kümmert er sich ja um was …
Ups. Ich hab da was verwexelt… Der crowdserver ist up and
running. Down ist alliednetworks.de.
„mirage“ würde die Mails erstmal annehmen, bis Du einen einen anderen Server laufen hast. Du solltest ihn – falls Du das willst – als MX mit niedrigerer Priorität ins DNS nehmen.
Sebastian