Re: Zwei NIC's mit der gleichen IP
Guten Tag, Ingo Juergensmann.
Am Mittwoch, 28. März 2007 15:04 schrieben Sie:
> On Wed, Mar 28, 2007 at 02:22:32PM +0200, Christian Wohlgemuth wrote:
> > Matthias Houdek schrieb:
> > >Hallo Ingo Juergensmann, hallo auch an alle anderen
> > >
> > >>Kurzum: eine Bridge ist ein Ding, was mehrere Interfaces mit
> > >> einer gemeinsamen IP haben kann.
> > >
> > >Flacsh.
> > >Eine Bridge ist ein Ding im Netzwerk, was typisch keine IP-Adresse
> > > hat. Es verbindet nämlich zwei Netzsegmente auf der physischen
> > > Ebene miteinander. Es ist also etwas ähnliches wie ein Switch
> > > oder Hub und dient lediglich der Wieterleitung der Datenpakete in
> > > ein anderes Netzsegment.
Ok, also "Krümelkacken" ;-)
> *augenverdreh*
> Wenn du es schon so genau haben moechtest, dann ist ein Switch ein
> Layer 2 Geraet, ein Hub aber ein Layer 1 Geraet, also ein
> Multiport-Repeater.
Die Begriffe Hub und Switch sind eh nicht eindeutig (z.B. gibt es auch
Layer-3-Switche; ein Hub als Layer-1-Gerät ist genauer genommen ein
Multi-Port-Repeater, ein "landläufiger" Switch nix anderes als eine
Multi-Port-Bridge).
> Meine kurze Zusammenfassung war eben genau das:
> eine kurze Zusammenfassung. Der Vollstaendigkeit wegen hatte ich ja
> auch den Link auf den Wikipedia Artikel mitgeliefert. Dass eine
> Bridge eine IP-Adresse haben *kann* impliziert ja nun auch, dass sie
> es nicht unbedingt haben *muss*.
Das war aber IMHO sehr missverständlich: "eine Bridge ist ein Ding, was
mehrere Interfaces mit einer gemeinsamen IP haben kann."
Eine Bridge hat typischer Weise keine IP - was nicht dem widerspricht,
dass ein Gerät, welches u.a. auch als Bridge arbeitet, nicht darüber
hinaus weitere Funtionen haben kann.
> Und darueberhinaus ist eher die
> Darstellung von dir, Matthias, falsch, da eher die Hubs (Layer 1)
> eine physische Verbindung herstellen (gemeinsame Kollisionsdomaene),
> waehrend die Bridges/Switches eine Kollisionsdomaene segmentieren,
> aber noch eine gemeinsame Broadcastdomaene bieten, also eben nicht
> mehr auf dem Physical Layer arbeiten, sondern auf dem Data Link
> Layer. Siehe auch dazu:
> * http://de.wikipedia.org/wiki/CSMA/CD
> * http://de.wikipedia.org/wiki/OSI-Modell
OK, ich schrub ja auch "etwas ähnliches wie". Und allgemein betrachtet
ist ein Switch auch ein Hub, und in der Anfangszeit wurden sie auch so
genannt: Switch-Hubs. Ein Switch ist ein auf alle Ports bridgender
Hub - dieser Satz ist (mal abgesehen vom scheußlichen Denglisch)
logisch völlig korrekt.
Außerdem sprach ich von der physischen Ebene, nicht vom "Physical
Layer".
OSI-Layer 1 und 2 bilden die physische oder Übertragungs-Ebene,
OSI-Layer 3 und 4 die Adressierungs- bzw. Protokollebene und die
OSI-Layer 5-7 die Anwendungsebene.
> Eigentlich dachte ich, dass die Einleitung meines Satzes mit
> "Kurzum:" schon Zeichen genug waere, dass es verkuerzte und nicht
> unbedingt 100%ig hieb- und stichfeste, aber vereinfachte
> Zusammenfassung folgen wuerde. Und um weiteren
> Missverstaendnissen/Fehlinterpretationen vorzubeugen: Dass man einer
> Bridge eine IP-Adresse geben kann, liegt nicht an der Bridge, sondern
> am daraufaufsetzenden TCP/IP Stack (obacht: das geht ab Layer 3 (IP)
> los und hoert nicht mit Layer 4 (TCP/UDP) auf, sondern reicht bis
> hinauf in Layer 7 (schliesslich sollen dort ja auch noch Dienste und
> andere Applikationen laufen)).
Eine Bridge hat aber typischer Weise keinen IP-Stack.
> Wie dem auch sei:
> Ich denke, dass eine Bridge eine einfache Moeglichkeit ist, das Ziel
> des OPs zu erreichen. Letzendlich muss er entscheiden, ob er lieber
> mit irgendwelchen Scripten herumhantieren oder eine solide Technik
> benutzen moechte.
Ich finde es eher abartig (ohne erst einmal die Funktionalität in Abrede
stellen zu wollen), einen Mechanismus zweckzuentfremden (denn eine
Bridge dient nicht der Vereinigung einer IP auf mehrere Devices). Da
wäre IMHO der Verweis auf Spanning Tree oder Loop-Detection
intressanter gewesen.
Die Lösung über Scripte scheint mir aber der sauberste Weg zu sein,
sofern er die physische Verbindung nicht während einer Session ändert.
Und selbst das dürfte in den meisten Fällen keine Probleme aufwerfen,
die das System nicht automatisch löst.
Gedankenexperiment - nicht verifiziert:
Was passiert eigentlich, wenn auf dem Notebook beide NIC gleichzeitig
mit der gleichen IP konfiguriert werden und die Priorisierung einer
Verbindung über die lokale Routingtabelle erfolgt (die lokale Route
über das Kabel-Device vor der lokalen Route über das WLAN)?
Von außen:
Ist nur ein Device im Netz verbunden, ist die Sache klar.
Sind beide Devices im Netz, wird die MAC von dem Device in die ARP-Table
eingetragen, das zuerst geantwortet hat. Alle weiteren Pakete an diese
IP gehen dann über diesen Weg. Wird auf ein Paket vom Notebook
geantwortet, dann sowieso an die MAC, von der das Paket kam (weil ggf.
die ARP-Table umgeschrieben wird).
Von innen:
Die Device-Auswahl erfolgt über die Routing-Table, geht also zunächst
über eth0 raus und erst wenn die Route nicht erreichbar über wlan0.
Problematisch könnte es höchstens werden, wenn zwischen beiden Devices
eine Bridge aktiviert wurde. Dann könnte ein Loop im Netz entstehen.
IMHO wäre also eine Bridge sogar problematisch. Zumindest ohne
Spannig-Tree-Algorithmus.
---- Ende des Gednakenexperiments ------
Also wird es wohl doch das Einfachste und Sicherste sein, bei Einstecken
eines (aktiven) LAN-Kabels das WLAN-Modul vorübergehend zu
deaktivieren.
--
Gruß
MaxX
Bitte beachten: Diese Mailadresse nimmt nur Listenmails entgegen.
Für PM bitte den Empfänger gegen den Namen in der Sig tauschen.
Reply to: