Zwei Router hintereinander schalten

So, nachdem wir jetzt ermittelt haben, wer den Längsten hat, will der arme TE vieleicht nochmal aus der Deckung kommen und sagen, was er eigentlich vorhat. Und welche Geräte er genau besitzt.
...
Du bist echt ganz besonders cool :cool:
...
PS: Ich kenne eigentlich keine DSL-Router, bei denen man das Routing abschalten kann.
...
Fritz!Box
...
Aber geroutet wird bei den mir bekanten Geräten immer nur zwischen WAN-Port und dem Rest (Switch+WLAN)
...
Gibt auch (DSL-)Router , bei denen man auf dem LAN-Port (bzw. dem damit verbundenen Switch) mehrere IP Adressen einrichten kann zwischen denen man routen kann. Ist aber zugegebenermaßen im unteren Preissegment (Consumer-Geräte) die Ausnahme.
 
Solange sie IP-Adressen aus verschiedenen Ranges vergeben, kollidiert da gar nichts.

Ich hatte damit allerdings schon Probleme (ok, einer der beiden war damals ein Win98-Host mit aktiviertem Internetsharing :eek:).
Aber vor allem wird im Regelfall der nachgelagerte Router auch kein Default-GW und DNS-Server kennen und daher werden die Clients dann Probleme bekommen. Also wie auch immer, würde ich der EInfachheit empfehlen, den als Switch eingesetzten nachgelagerten Router vom DHCP-Serving zu befreien.

Du bist echt ganz besonders cool :cool:
Nicht ärgern!
Unser "Fachgesimpel" hatte doch keinen großen praktischen Nutzwert, schon gar nicht für den TE (vermute ich).
Übrigens: Es würde mich wirlich interessieren, welche low-end-DSL-Router dynamisch routen können.

Also verbinde ich die zwei Router jeweils per Lan Port. Ok.
Beim ersten Router feste IP und DHCP abschalten.
Bei der TC noch die feste IP vom ersten Router eintragen. Vermutlich unter den DHCP Einstellungen. Mal sehen.
Und dann noch Bridge Modus aktivieren.
Stimmt das?
Ich meinte den inneren Router: per LAN-Port "uplinken", DHCP-Server aus. Wenn er einen Bridge Modus hat, kanst Du auch den WAN Port nehmen. (Generisch für "übliche" o8-15 Router gesprochen)
Der DSL-Router wird seine exteren IP dynmisch vom Provider erhalten - wie auch immer, wenn der geht, einfach so lassen!
 
Zuletzt bearbeitet:
...
Nicht ärgern!
Unser "Fachgesimpel" hatte doch keinen großen praktischen Nutzwert, schon gar nicht für den TE (vermute ich).
Übrigens: Es würde mich wirlich interessieren, welche low-end-DSL-Router dynamisch routen können.
...
Ich ärger mich nicht.
Allerdings bin ich der Meinung, dass eine solche Diskussion sicherlich von vielen Interessierten gelesen wird. Da darf dann auch ein wenig weiterführende Information dabei sein. Der TS profitiert da u.U. auch davon.
Zu Deiner Frage: Ich hatte vor Jahren z.B. mal einen (billigen) Zyxel Router, der konnte RIP I und RIP II, man konnte die Routing Tabelle von Hand manipulieren und man konnte den LAN Ports mehrere Adressen zuweisen und zwischen denen routen.
 
Solange sie IP-Adressen aus verschiedenen Ranges vergeben, kollidiert da gar nichts.
So aus dem Zusammenhang gerissen sieht das schon so aus. Aber was passiert denn wenn man Router1 und 2 einfach über LAN-Ports verbindet und beide DHCP in unterschiedlichen Ranges haben, Richtig man kann nicht vorhersagen aus welchem IP-Range die Adresse kommt. Ist zwar keine Kollision, aber eigentlich noch unerwünschter.
 
... man kann nicht vorhersagen aus welchem IP-Range die Adresse kommt. Ist zwar keine Kollision, aber eigentlich noch unerwünschter.
:confused:
Solange die IPs aus dem richtigen Netz kommen, wäre das kein Hinderungsgrund!
 
Zuletzt bearbeitet:
Wenn Du die Router nur über die LAN-Ports wie in meinem Ausgangsposting beschrieben zusammenhängst, hängen ja beide in einem nich voneinander getrennten Netz, daher lässt sich keine Vorraussage treffen welcher DHCP antwortet. Da ja über einen Broadcast gefragt wird. Man bekommt die IP immer von dem der schneller antwortet. Aber wie im vorigen Posting geschrieben das war etwas aus dem Zusammenhang gerissen. Weil welches wäre denn jetzt das richtige Netz?
 
Ich habe den 1. (Modem-)Router an den WAN-Port des zweiten Routers geschaltet. Dann habe ich dem 2. Router eine andere Adresse verpasst und beiden Routern die gleiche Subnetmask gegeben. Und schon hat es funktioniert. :cake:
 
Ich kenne eigentlich keine DSL-Router, bei denen man das Routing abschalten kann.

Wie ich oben schon schrieb. Hier muss man den funktionalen Zusammmenhang zwischen Routing und NAT bei einem DSL-Router sehen. Du mußt nur NAT deaktivieren, dann findet kein Routing mehr statt.Und NAT deaktivieren kann man auch bei Ur-Alt-Routern.
 
Wie ich oben schon schrieb. Hier muss man den funktionalen Zusammmenhang zwischen Routing und NAT bei einem DSL-Router sehen. Du mußt nur NAT deaktivieren, dann findet kein Routing mehr statt.
Das ist in dieser Verallgemeinerung absoluter Unsinn.

Routing und NAT sind zwei völlig unabhängige Dinge. Routing läuft auf dem Layer drei des ISO/OSI Modells, NAT auf dem Layer drei und (hauptsächlich) vier. Mal ganz abgesehen davon, dass es unterschiedliche Arten von NAT gibt, die z.T. große Unterschiede aufweisen und bei DSL Routern (um die es hier ja geht) i.d.R genau genommen PAT (bzw. NAPT) angewendet wird.
 
Routing und NAT sind zwei völlig unabhängige Dinge

Es wäre schön, wenn du den genaueren Wortlaut meiner Beiträger korrekt zur Kenntnis nehmen würdest. Es macht wenig Freude, mit Leuten zu diskutieren, die nicht in der Lage sind, sprachliche Differenzierungen wahrzunehmen.

Ich habe an keiner Stelle behauptet, dass NAT und Routing identisch sind, sondern dass mit der Abschaltung von NAT bei gängigen DSL-Routern kein Routing mehr stattfindet. Deshalb geht eine technische Erläuterung dessen, was NAT und Routung grundsätzlich bedeuten, in diesem Kontext an meiner Argumentation völlig vorbei.

Ich würde dir empfehlen, mal einen Volkshochschulkurs im korrekten Lesen zu belegen. Da scheint es bei dir gewisse Schwächen zu geben.
 
Es wäre schön, wenn du den genaueren Wortlaut meiner Beiträger korrekt zur Kenntnis nehmen würdest. Es macht wenig Freude, mit Leuten zu diskutieren, die nicht in der Lage sind, sprachliche Differenzierungen wahrzunehmen.
...
Es wäre schön, wenn Du technische Sachverhalte sprachlich so differenziert darstellen würdest, dass sie unmissverständlich technisch korrekt sind.

So wie Du es in Deinem vorletzten Posting schreibst ist es einfach nur falsch. Das Wort "gängig", das Du jetzt zu Deiner Rechtfertigung hier einzuschmuggeln versuchst, ist in Deinem vorletzten Posting nicht enthalten und würde zudem nichts an der technischen Unschärfe Deiner Aussage ändern.

Im Übrigens solltest Du Dir angewöhnen, technische Kritik und persönliche Beleidigungen voneinander zu unterscheiden.
Wenn Du eine andere Meinung hast, kannst Du gerne mit diskutieren, aber nicht so!
 
Wenn Du die Router nur über die LAN-Ports wie in meinem Ausgangsposting beschrieben zusammenhängst, hängen ja beide in einem nich voneinander getrennten Netz, daher lässt sich keine Vorraussage treffen welcher DHCP antwortet. Da ja über einen Broadcast gefragt wird. Man bekommt die IP immer von dem der schneller antwortet. Aber wie im vorigen Posting geschrieben das war etwas aus dem Zusammenhang gerissen. Weil welches wäre denn jetzt das richtige Netz?

Genau. Technisch kann überhaupt nur der antworten, der sich selbst in der selben Broadcastdomäne befindet. Meine Aussage war, dass theoretisch zwei DHCP-Server in einer Brodcastdomäne koexistieren können, wenn Sie a) niemals die gleiche vergeben dürfen (nicht überlappende Bereiche) und b) ("richtiges Netz") dem Client eine IP für das für ihn richtige Netz geben. (Hintergrund: es ist nicht sichergestellt, dass der DSL-Router in diesem Kontext IPs auch dem richtigen Netz vergibt - das muss man halt sicherstellen).

Thomas
 
Genau. Technisch kann überhaupt nur der antworten, der sich selbst in der selben Broadcastdomäne befindet. Meine Aussage war, dass theoretisch zwei DHCP-Server in einer Brodcastdomäne koexistieren können, wenn Sie a) niemals die gleiche vergeben dürfen (nicht überlappende Bereiche) und b) ("richtiges Netz") dem Client eine IP für das für ihn richtige Netz geben. (Hintergrund: es ist nicht sichergestellt, dass der DSL-Router in diesem Kontext IPs auch dem richtigen Netz vergibt - das muss man halt sicherstellen).

Thomas


Edit Falsch gelesen. Ok in meinem BSP würden sich beide Router in der selben Domaine befinden. Ich habe schon arge Probleme mit zwei DHCPs im Netz gehabt. Da hat doch glatt jemand in unserem Netzwerk ungewollt nen zweiten DCHP aufgemacht und schwups war unser Windows 2003 Server nicht mehr dazuzubewegen den DHCP anzuschalten und wir hatten ein arges Problem. Vorallem erstmal Rauszufinden welcher Schwachmat seinen Router von zu Hause mitbringt um sich ein WLAN im Firmennetzwerk anzulegen. In dem Fall waren es komplett unterschiedliche IP-Ranges, aber trotzdem Hat der Windows DHCP Server nichts mehr gemacht.
 
Nur noch mal zur Klarheit: Ich habe auch schlechte Erfahrungen mit doppelten DHCP-Servern gemacht und bin generell "dagegen", aber die Tatsache an sich, dass zwei korrekte konfigurierte DHCP-Server nebeneinander arbeiten, zB auch aus Loadsharing- und Ausfallschutz-Gründen, wäre theoretisch ok. Auch wenn es unvorhersagbar ist, welcher antwortet.

Anyway.
Der TE ist nun immer noch nicht weiter ;)

Thomas
 
Vorallem erstmal Rauszufinden welcher Schwachmat seinen Router von zu Hause mitbringt um sich ein WLAN im Firmennetzwerk anzulegen. In dem Fall waren es komplett unterschiedliche IP-Ranges, aber trotzdem Hat der Windows DHCP Server nichts mehr gemacht.

Da muss niemand seinen Router mitbringen. In vielen solchen Fällen liegt die Ursache darin, dass Leute ihre Vmware-Installation mit aktiviertem Vmware-internen DHCP-Server laufen haben.
 
In unserm Fall wars halt der Mensch mit dem WLAN Router.
 
...
aber die Tatsache an sich, dass zwei korrekte konfigurierte DHCP-Server nebeneinander arbeiten, zB auch aus Loadsharing- und Ausfallschutz-Gründen, wäre theoretisch ok. Auch wenn es unvorhersagbar ist, welcher antwortet.
...
Das sehe ich auch so und zwar selbst dann, wenn beide Server Adressen aus dem selben Range vergeben. Das DHCP Protokoll stellt ja sicher, dass nicht eine Adressen an mehrere Geräte vergeben werden kann. Problematisch wird es allerdings dann, wenn statische Adressen haben möchte, was IMO dem Sinn und Zweck von DHCP einigermaßen zuwider läuft.
 
Problematisch wird es allerdings dann, wenn statische Adressen haben möchte, was IMO dem Sinn und Zweck von DHCP einigermaßen zuwider läuft.
Es kann schon Sinn machen die IPs feste zu vergeben. Die Informationen über DNS, Gateway usw aber per dhcp. So kann man ohne Eingriffe auf die clients z.B. einen neuen Nameserver oder ein neues Gateway ins Netz bringen.

Ansonsten:
Hier hingen auch zwei router hintereinander.
Ein Speedtouch von tele2 und dahinter mein openwrt-router.
Allerdings bin ich froh das tele2 hier Geschichte ist, das hat aber nix mit den zwie Routern zu tun :)
 
Da würde ich gerne mal eine Frage einwerfen. Und zwar habe ich an einer Fritz!BoxFon die den Internet Zugang herstellt einen AP für das WLAN hängen. Das ganze läuft mit DHCP von der Fritz!Box und funktioniert auch ganz prima, allerdings frage ich mich, was das hier zu bedeuten hat:
$ ping 192.168.178.255
PING 192.168.178.255 (192.168.178.255): 56 data bytes
64 bytes from 192.168.178.32: icmp_seq=0 ttl=64 time=2.376 ms
64 bytes from 192.168.178.1: icmp_seq=0 ttl=64 time=4.836 ms (DUP!)
64 bytes from 192.168.178.21: icmp_seq=0 ttl=64 time=32.694 ms (DUP!)
64 bytes from 192.168.178.32: icmp_seq=1 ttl=64 time=2.317 ms
64 bytes from 192.168.178.21: icmp_seq=1 ttl=64 time=3.698 ms (DUP!)
64 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=4.140 ms (DUP!)

Wenn ich die IPs direkt anpinge kommen keine DUPs, also ist alles im grünen Bereich, oder habe ich das hier jetzt falsch verstanden?


Dem Threadersteller drücke ich die Daumen, viele Geräte sind auch für diese Betriebsart ausgelegt. Ich kenne die TimeCapsule aber leider nicht.

// ich hab den Link zu ping mal eingefügt, ich habe mir das tatsächlich durchgelesen, bevor ich hier geposted habe. Ich würde mich wirklich sehr über eine einfache Antwort freuen. Oder anders gesagt:

macuser:~ Lofgard$man ping -h | grep grüner\ Bereich

/// ok, dann scheint alles ok zu sein. Ich habe die Duplikate seit ich den Router als AP laufen habe, vorher waren die nicht da, obwohl sie laut der ping manpage da ja auch zu erwarten wären… (Witz! Ich will jetzt nicht wirklich wissen, warum die vorher nicht da waren, aber so ist das halt wenn Halbwissen und Linux zusammentreffen, man wundert sich ab und zu.)
 
Zuletzt bearbeitet:
@magheinz
Da stelle ich ja prinzipiell gar nicht in Abrede. DHCP wurde aber ursprünglich nicht für solche Zwecke entwickelt und ist dafür nicht optimiert; das merkt man dem Protokoll eben an. "Früher" waren Clients halt einfach nur Clients und brauchten keine festen IP Adressen zu haben.

@lofgard
Die manpage zu ping gibt dazu folgende Auskunft:
Code:
DUPLICATE AND DAMAGED PACKETS
     The ping utility will report duplicate and damaged packets.  Duplicate
     packets should never occur when pinging a unicast address, and seem to be
     caused by inappropriate link-level retransmissions.  Duplicates may occur
     in many situations and are rarely (if ever) a good sign, although the
     presence of low levels of duplicates may not always be cause for alarm.
     [B]Duplicates are expected when pinging a broadcast or multicast address,
     since they are not really duplicates but replies from different hosts to
     the same request.[/B]

     Damaged packets are obviously serious cause for alarm and often indicate
     broken hardware somewhere in the ping packet's path (in the network or in
     the hosts).
Das sollte die Frage beantworten. Achte auch auf die icmp_seq Nummer.
 
Zuletzt bearbeitet:
Zurück
Oben Unten