Netzwerk: Routing über zwei Interfaces

Ich hab jetzt mal ne Weile gegoogled, weil mich das inetressiert, denn auf einem aktuellen macOS funktioniert das sofort, beide Interfaces behalten ihre IP.
Und das ist schon lustig, da fragen viele Leute genau nach deinem Anwendungsfall und bekommen zu 99% Erklärungen die nich dazu passen, entweder wird ihenen erklärt, das der Mac sich automatisch die richtige Verbindung sucht anhand der Reihenfolge, oder es wird zu einem Programm geraten um die Interfaces zu bonden (Bündelung von zwei Anschlüssen für mehr Geschwindigkeit) oder es wird wie hier gesagt es "müsste einfach funkktionieren".

Ich bin da inzwischen bei @verstaerker, dass es eventuell an deiner Konfiguration liegt... schwer zu debuggen ohne Zugriff aufs Gerät.
 
loopy schrieb:
Das stimmt. In verschiedenen Netzen kann man ein Interface mit 2 verschiedenen IPs (v4) konfigurieren. IP v6 kann viel mehr. Aber der Rechner wäre dann aber selbst ein Gateway, oder? Vielleicht täusche ich mich mit der Zuweisung. Aber sollte nicht das Subnetz in welchem der Rechner sitzt, das gleiche sein? Auch brauchen beide Interfaces IP-Adressen...
Zum Vergrößern anklicken....
Nein und nein.
Ist hier aber der falsche Ort für einen Grundlagenkurs in Netzwerktechnik...
 
recliq schrieb:
Ich hab jetzt mal ne Weile gegoogled, weil mich das inetressiert, denn auf einem aktuellen macOS funktioniert das sofort, beide Interfaces behalten ihre IP.
Und das ist schon lustig, da fragen viele Leute genau nach deinem Anwendungsfall und bekommen zu 99% Erklärungen die nich dazu passen, entweder wird ihenen erklärt, das der Mac sich automatisch die richtige Verbindung sucht anhand der Reihenfolge, oder es wird zu einem Programm geraten um die Interfaces zu bonden (Bündelung von zwei Anschlüssen für mehr Geschwindigkeit) oder es wird wie hier gesagt es "müsste einfach funkktionieren".

Ich bin da inzwischen bei @verstaerker, dass es eventuell an deiner Konfiguration liegt... schwer zu debuggen ohne Zugriff aufs Gerät.
Zum Vergrößern anklicken....
bei mir stehen alle auf DHCP mit manueller Adresse, im Router sind den 3 Macs und dem NAS feste IPs zugewiesen.
 
recliq schrieb:
Nein und nein.
Ist hier aber der falsche Ort für einen Grundlagenkurs in Netzwerktechnik..
Zum Vergrößern anklicken....
Du hast recht, meinte ich vorher. IP Aliasing nennt sich das.
Vielleicht kann man mit MAC-Adress Filterung irgendwie hinkriegen? Und IP Adressen für beide Interfaces.....
 
loopy schrieb:
Du hast recht, meinte ich vorher. IP Aliasing nennt sich das.
Vielleicht kann man mit MAC-Adress Filterung irgendwie hinkriegen? Und IP Adressen für beide Interfaces.....
Zum Vergrößern anklicken....
Ja dann filter mal schön MACs, wo, wie und wozu auch immer... leider wird es Florian bei seinem Problem nicht weiterbringen.
 
Ethernet (Rechner) MAC nur durch bestimmten Router
WLAN (Rechner) MAC für seinen WLAN Router
Sollte doch mit ACLs funktionieren?

Meine praktische Erfahrung erschöpft sich ein wenig, aber ich finde das Thema sehr interessant...Kenn mich mit Macintoshs nicht so gut aus....aber danke für die konstruktive Kritik....
 
Nachmal für alle: Das Problem ist nicht direkt routingtechnischer Natur, sondern das eines der Interfaces seine IP verliert sobald das andere eingeschaltet wird... ohne IP nix TCP/IP.
Ich bin hier raus, das Netzwerkkompetenz-Team (der Bundesregierung?!? des Neuland?!?) ist ja anscheinend vollzählig anwesend.
 
Eine NIC kann nicht gleichzeitig in 2 Subnets erreichbar sein, oder? Vielleicht eine VLAN Lösung vonnöten?
 
analog guy schrieb:
@fanwander schreibt:
Mein Problem: sobald ich das WLAN aktiviere, wir das Netzwerksetting des Ethernet-Aschlusses deaktiviert.

Das ist mehr als "IP verlieren". Darum mein Hinweis auf virtuelle Adapter, weil sowas schon bei virtuellen VPN Adapter beobachtet habe - gerade im Enterprise Umfeld gibt es Konfigurationen, die andere Interfaces killen, um das Routing zwischen der Interfaces zu verunmöglichen.
Zum Vergrößern anklicken....
Ja, aber dann lies alles und schau dir seine Ausgabe von ifconfig an... das Interface ist "UP, RUNNING" und "active"...
 
Hier ein interessanter Link zu Multihomed Hosts: (Wikipedia, englisch, die deutsche Übersetzung ist miserabel):

Multihoming - Wikipedia

en.wikipedia.org en.wikipedia.org

Kann Lösungsansätze bieten, ist aber leider nur auf hoher Abstraktionsebene formuliert. Aber interessant!

Ein weiterer Link zu Multihomed Hosts: https://blog.ipspace.net/2009/06/multihomed-ip-hosts.html

oder etwas anschaulicher hier: https://networklessons.com/cisco/cc...-105/singledual-homed-and-multi-homed-designs

sehr hilfreich auch: https://www.ibm.com/docs/en/spectrum-symphony/7.3.1?topic=cpus-multi-homed-hosts
 
Zuletzt bearbeitet:
Was statisches Routing beim Mac OS angeht hier ein weiterer Link:


PS: Immer ein Backup der ursprünglichen Konfiguration erstellen! Also ein Image!
 
Zuletzt bearbeitet:
@loopy
und nochmal: das hilft hier genau wie? Richtig, gar nicht!
Post 1 beschreibt die die Theorie und Anwendungsgebiete von mehreren IPs auf einem Gerät - ist bekannt und nicht hilfreich
Post 2 erklärt etwas zu statischen Routen unter macOS - ohne IP aber auch kein Routing, wieder nicht hilfreich

@lowcust eine Route wird immer benötigt, der Rechner muss ja wissen zu welchem Interface (bei mehreren) er seine Pakete schicken muss. Im Normalfall wird diese Route aber automatisch hinzugefügt, sobald ein Interface mit einem neuen Netz aktiv wird.
 
aven schrieb:
Der Plan ist folgender….
Anwendung A - Ethernet - Netz 192.168.178.0/24
Anwendung B - WLAN. - Netz 192.168.12.0/24

Grundsätzlich geht das.

Problem ist halt das sich beim aktivieren des WLANs, das Ethernet deaktiviert.
Zum Vergrößern anklicken....
Wenn man die Netzwerke erreichen möchte braucht man 255.255.0.0 also /16 dann aber auf die Gateway achten sofern nötig, man sollte sowas vorab planen per Subnetting wenn es die Host Anzahl zulässt. Davon gehe ich aber in einem Privathaushalt aus.
 
Habe mir die Mühe gemacht und das ifconfig nochmals gründlich gecheckt. Danach ein Netzwerk-Diagramm erstellt. Vielleicht hilfts?Z.jpg
 
Zuletzt bearbeitet:
recliq schrieb:
Ich geb endgültig auf.
Zum Vergrößern anklicken....
Bitte nicht. IT-Support kann manchmal frustrierend sein, aber ist so was wie Bergsteigen. Deine Beiträge sind wertvoll! Manchmal müssen Supporter viel, viel lesen und manchmal auch abstrahieren können. Gelingt mir vielmals auch nicht (sofort)!
 
lowcust schrieb:
Wozu eine statische Route innerhalb eines Local LAN?
Zum Vergrößern anklicken....
Weil das nicht 1 Subnetz ist, sondern 2. Da der Adressbereich der 2 Subnetze verschieden ist, routet man 1 Interface statisch an einen Router und der 2. Adressbereich an den anderen Router. Ein LAN-Segment ist per se ein Subnetz (Broadcast Domain) im Vergleich zu einem einzigen Adressbereich (Collision Domain).
 
Nochmals: ich habe KEIN ROUTINGPROBLEM.

Ich habe das Problem, dass das Interface-Management von Mac OS anders "tickt", als ich es von der Standard-Unix-Administration gewöhnt bin. Insofern ist der Hinweis von Freund @fairplay in #30 auf das NSNetwork Framework wohl der richtige.

Ich werde das nochmal im abgesicherten Modus versuchen. Ansonsten, muss ich halt mit der langen Sleep-Zeiten im Setup der ETC leben (die ganze Aktion ist ja eigentlich ein Workaround für das Problem der Critter ETC).
 
loopy schrieb:
Weil das nicht 1 Subnetz ist, sondern 2. Da der Adressbereich der 2 Subnetze verschieden ist, routet man 1 Interface statisch an einen Router und der 2. Adressbereich an den anderen Router. Ein LAN-Segment ist per se ein Subnetz (Broadcast Domain) im Vergleich zu einem einzigen Adressbereich (Collision Domain).
Zum Vergrößern anklicken....
Nein, da muss gar nichts geroutet werden, die Interfaces sind in den entsprechenden Netzen. Routen musst du nur, wenn du in ein nicht direkt anliegendes Netz willst, was hier nicht zutrifft.
Dein letzter Satz ist ein buntes Durcheinander von Begrifflichkeiten aus Layer 2 und Layer 3.
 
fanwander schrieb:
Ich werde das nochmal im abgesicherten Modus versuchen. Ansonsten, muss ich halt mit der langen Sleep-Zeiten im Setup der ETC leben (die ganze Aktion ist ja eigentlich ein Workaround für das Problem der Critter ETC).
Zum Vergrößern anklicken....

Ich finde es grundsätzlich ziemlich eigenartig, dass man die Kiste nicht sauber konfigurieren kann, bzw. das was an Dokumentation schnell suchbar ist, doch eher stark zu wünschen übrig lässt.

Ich würde an deiner Stelle mal den Support anschreiben und die fragen, was man bitte machen muss, um das Ding in ein vorhandenes WLAN einzubinden. Und dass es scheinbar drauf besteht, einen eigenen AP unter einer spezifischen IP-Adresse aufzumachen, scheint mir spätestens dann ziemlich dämlich zu sein, wenn man zwei (oder mehr) verschiedene Einheiten davon gleichzeitig per WLAN ansprechen und on-the-fly konfigurieren will. Wenn sich beide ETC dann mit 192.168.12.1 als AP um die selben Frequenzen und logischen IP-Adressen prügeln, dann ist das doch eher ziemlicher Unfug. Da muss es irgendeine sinnvolle Strategie geben, die ich aber nicht mal eben so anhand der Dokumentation finden konnte.
 
2bit schrieb:
Ich finde es grundsätzlich ziemlich eigenartig, dass man die Kiste nicht sauber konfigurieren kann, bzw. das was an Dokumentation schnell suchbar ist, doch eher stark zu wünschen übrig lässt.
Zum Vergrößern anklicken....
DAs liegt daran das mit einem Mac einfach immer alles einfach funktioniert...


..scnr..
 
Naja, die Critter&Guitari-Devices scheinen jedes für sich ein ziemlich vollständiges unixoides Betriebssystem mitzuschleppen, auf denen dann auch ein Python-Environment läuft. Das hat mit den Quirks eines Macs dann auch erstmal gar nix zu tun.


Das muss sich imho vernünftig einstellen lassen, damit es auch genau das tut, was man eben braucht.
 
2bit schrieb:
Das muss sich imho vernünftig einstellen lassen, damit es auch genau das tut, was man eben braucht.
Zum Vergrößern anklicken....
Es ist ganz einfach: meine netzwerkseitige Modifikation an der ETC funktioniert netzwerktechnisch einwandfrei. Was nicht funktioniert, ist das Umstellen der IP während Pygame läuft. Das ist auch auf anderen Rechnern nachvollziehbar.
Wenn ich den IP-Wechsel so vor python/pygame starte, dass der IP-Wechsel garantiert komplett durch ist, dann läuft auch pygame einwandfrei. Die dafür erforderliche Wartezeit will ich aber vermeiden.

(hab ich eigentlich alles schon im ersten Post des Threads geschrieben, aber die Jugend von heute hat ja keine Geduld, also wiederholen wir es halt hier nochmal.... :opa:)
 
fanwander schrieb:
Es ist ganz einfach: meine netzwerkseitige Modifikation an der ETC funktioniert netzwerktechnisch einwandfrei. Was nicht funktioniert, ist das Umstellen der IP während Pygame läuft. Das ist auch auf anderen Rechnern nachvollziehbar.
Zum Vergrößern anklicken....

Dann ist die ebenso einfache Antwort: Das Python-Script arbeitet fehlerhaft und lässt dich zwei Minuten lang sinnlos warten. -> Den Developer damit nerven.

fanwander schrieb:
(hab ich eigentlich alles schon im ersten Post des Threads geschrieben, aber die Jugend von heute hat ja keine Geduld, also wiederholen wir es halt hier nochmal.... :opa:)
Zum Vergrößern anklicken....

Mal ehrlich, was soll denn dieser Spruch? Du hast doch klar mitgeteilt, dass das Arch-Linux auf dem ETC zusammen mit Python hier die Faxen macht und darauf hab ich mich auch bezogen. Da ist doch das eigentliche Problem zu lösen und nicht auf dem Macbook.
 
Zuletzt bearbeitet:
2bit schrieb:
Mal ehrlich, was soll denn dieser Spruch? Du hast doch klar mitgeteilt, dass das Arch-Linux auf dem ETC zusammen mit Python hier die Faxen macht und darauf hab ich mich auch bezogen. Da ist doch das eigentliche Problem zu lösen und nicht auf dem Macbook.
Zum Vergrößern anklicken....
Nein, nicht so ganz, denn das Macbook verhält sich auch nicht wie man es erwarten würde, würde es das tun wäre auch dies eine (vermutlich sogar einfachere und schnellere) Lösung des Problems, verglichen mit dem Aufwand an Zeit und Nerven bis der Entwickler der Software den vermeintlichen Bug eventuell fixed. Ich kann @fanwander und seine Intention da schon sehr gut verstehen und nachvollziehen.
 
2bit schrieb:
Dann ist die ebenso einfache Antwort: Das Python-Script arbeitet fehlerhaft und lässt dich zwei Minuten lang sinnlos warten. -> Den Developer damit nerven.
Zum Vergrößern anklicken....
Das hat nichts mit dem Python Script zu tun, sondern mit Pygame bzw eigentlich mit dem der Konsolenansteuerung von Linux. Die Problematik lässt sich auch mit dem Pygame Standard-Test reproduzieren mit dem ca 8 Millionen Gameentwickler arbeiten (ich hab es mit Pygame 2 und Pygame 3 getestet - ich würde ja sogar ETC auf pygame 3 umschreiben). Sobald man SDL_VIDEODRIVER auf fbcon routet, hängt sich bei einer nachfolgenden IP-Änderung der Pygame output auf einen neuen Socket; das Display selbst erwartet aber Daten auf dem alten Socket. Es hilft auch offesichtlich nix, wenn man die Definition von IP und SDL_VIDEODRIVER vertauscht, da das erst nach einem timeout passiert.
Ich muss also - egal - wie die Reihenfolge ist, immer einen sleep in die Abfolge reinhängen, um diesen timeout auszutricksen. Würde man wayland oder x11 benutzen, so könnte man einen Restart des Display-Servers machen. Aber das ist auf der Hardware der ETC nicht machbar.
Deswegen ist die von mir in #13 angedacht Abänderung der Systemd-Abhängigkeiten auch keine Lösung, weil dann halt die Timeoutzeit in den Systemboot reinverschoben würde - und mir geht es ja darum, bei Stromausfall (Bühnensituation!) das System, so schnell wie nur irgend möglich am Laufen zu haben.
 
Zuletzt bearbeitet:
Ich kenn diese ETC-Box nicht, komme jetzt aber etwas ins Schlingern, warum Du da einen IP-Wechsel machen musst... ich rate jetzt mal: Die ETC hat eine fixe IP/IP-subnet konfiguriert. Will man das ändern, fährt die Kiste jedesmal mit der Default IP hoch und wechselt dann auf die konfigurierte IP, was zu dem Timeout führt? Wie auch immer, was ggf. auch ein Weg währe, die ETC in ihrem Netz zu belassen, direkt an die FritzBox zu hängen und in der Fritzbox das zusätzliche Netz zu konfigurieren inkl. der entsprechenden Routen. Damit könntest am Mac mit einer Verbindung arbeiten, was ohnehin weniger problembehaftet ist. Ich bin mir nicht sicher, wie man in aktuellen FritzBoxen zusätzliche Netzwerke konfigurieren kann, habe aber einen alten Thread gefunden wo das einer in seiner ar7.cfg direkt eingetragen hat: Link
 
Du musst dich einloggen oder registrieren, um hier zu antworten.


Neueste Beiträge

News

Zurück
Oben