ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
-
- Posts: 3
- Joined: 25 Mar 2019, 13:29
ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
Die letzten Tage hat sich ein merkwürdiges Verhalten bei dem RevpiConnect gezeigt, wo ich nun hoffe, dass uns hier jemand weiterhelfen kann.
Beschreibung :
Am Ethernet-Port B haben wir eine statische IP-Adresse (192.168.1.63) vergeben.
Am Ethernet-Port A hängen wir an einem DHCP-Server, der uns eine IP-Adresse aus dem selben Adressbereich zuweist (192.168.1.2)
Am Ethernet-Port B hängt in einer 1-1-Verbindung ein Rechner im gleichen IP-Adressbereich, aber mit einer im DHCP nicht vergebenen IP-Adresse (192.168.1.100).
Am Ethernet-Port A hängen über einen Switch oder ein Gateway mehrere Geräte, keins davon hat die IP-Adresse des Rechners an Port B.
Haben wir das Ethernet-Kabel an Port A nicht angesteckt, können wir auf Port B ohne Probleme das Gerät anpingen und uns per SSH darauf verbinden.
Haben wir das Ethernet-Kabel an Port A eingesteckt, kann der Rechner an Port B das Gerät nicht mehr anpingen und auch nicht per SSH darauf zugreifen.
Verbinden wir uns aber per SSH über Port A auf den RevPi, so sehen wir in der ifconfig-Abfrage, dass Port B weiterhin die statische IP-Adresse zugeteilt ist.
Hat hier noch jemand mit diesem Problem zu kämpfen gehabt und kann uns vielleicht weiterhelfen eine Loesung zu finden, ohne den Adressbereich des Port2 auf eine andere Adresse umbiegen zu müssen?
Gerade für den Einsatz in anderen Netzwerken, bei dem der DHCP-IP-Adressbereich des Port A von uns nicht beeinflussbar ist, brauchen wir dringend eine Lösung.
Beschreibung :
Am Ethernet-Port B haben wir eine statische IP-Adresse (192.168.1.63) vergeben.
Am Ethernet-Port A hängen wir an einem DHCP-Server, der uns eine IP-Adresse aus dem selben Adressbereich zuweist (192.168.1.2)
Am Ethernet-Port B hängt in einer 1-1-Verbindung ein Rechner im gleichen IP-Adressbereich, aber mit einer im DHCP nicht vergebenen IP-Adresse (192.168.1.100).
Am Ethernet-Port A hängen über einen Switch oder ein Gateway mehrere Geräte, keins davon hat die IP-Adresse des Rechners an Port B.
Haben wir das Ethernet-Kabel an Port A nicht angesteckt, können wir auf Port B ohne Probleme das Gerät anpingen und uns per SSH darauf verbinden.
Haben wir das Ethernet-Kabel an Port A eingesteckt, kann der Rechner an Port B das Gerät nicht mehr anpingen und auch nicht per SSH darauf zugreifen.
Verbinden wir uns aber per SSH über Port A auf den RevPi, so sehen wir in der ifconfig-Abfrage, dass Port B weiterhin die statische IP-Adresse zugeteilt ist.
Hat hier noch jemand mit diesem Problem zu kämpfen gehabt und kann uns vielleicht weiterhelfen eine Loesung zu finden, ohne den Adressbereich des Port2 auf eine andere Adresse umbiegen zu müssen?
Gerade für den Einsatz in anderen Netzwerken, bei dem der DHCP-IP-Adressbereich des Port A von uns nicht beeinflussbar ist, brauchen wir dringend eine Lösung.
Re: ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
Ich denke das Problem ist dass Du hier zwei Default Gateways verwendest. Im Tutorial 06 – WLAN einrichten gehe ich hier auf die Metrik ein, die hier eventuell eine Rolle spielt.
-
- Posts: 3
- Joined: 25 Mar 2019, 13:29
Re: ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
Das scheint leider unser Problem nicht zu loesen.
Wenn wir die Metrik abändern, koennen wir den Port B priorisieren. Ist dann aber ein Gerät angeschlossen, ist ein Ping von Port A ausgehend, als auch zu Port A eingehend nicht mehr moeglich.
Wenn wir die Metrik abändern, koennen wir den Port B priorisieren. Ist dann aber ein Gerät angeschlossen, ist ein Ping von Port A ausgehend, als auch zu Port A eingehend nicht mehr moeglich.
Re: ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
Hallo Christian,
Das ist Linux Routing spezifisch.
Beim Kabel stecken kommt es zu udev-Events, dessen Regeln dann das Netzwerk konfigurieren, also auch Default-Gateway einrichtet. Und in Linux
kannst Du auch mehrere Default-Gateways Einträge in der Routing Tabelle haben.
Das Problem ist hier, dass beide Ports sich im selben Netz 192.168.1.0/24 befinden. Davon ausgehend hast Du sicher keine statische
Host-Route eingerichtet, welche besagt, dass Pakete für 192.168.1.100 explizit über Port B gesendet werden sollen. Das Default-Gateway
konfigurierst Du mit dem eth-Device, welches Port A repräsentiert und entfernst Default-Gateway-Einträge, welche mit Port B zu tun haben.
Also Host Route für 192.168.100.100 über Port B einrichten , Default-Gateway-Eintrag für Port B entfernen, damit müsste alles gehen, so wie
Du es haben möchtest.
Liebe Grüße
Frank
Das ist Linux Routing spezifisch.
Beim Kabel stecken kommt es zu udev-Events, dessen Regeln dann das Netzwerk konfigurieren, also auch Default-Gateway einrichtet. Und in Linux
kannst Du auch mehrere Default-Gateways Einträge in der Routing Tabelle haben.
Das Problem ist hier, dass beide Ports sich im selben Netz 192.168.1.0/24 befinden. Davon ausgehend hast Du sicher keine statische
Host-Route eingerichtet, welche besagt, dass Pakete für 192.168.1.100 explizit über Port B gesendet werden sollen. Das Default-Gateway
konfigurierst Du mit dem eth-Device, welches Port A repräsentiert und entfernst Default-Gateway-Einträge, welche mit Port B zu tun haben.
Also Host Route für 192.168.100.100 über Port B einrichten , Default-Gateway-Eintrag für Port B entfernen, damit müsste alles gehen, so wie
Du es haben möchtest.
Liebe Grüße
Frank
-
- Posts: 3
- Joined: 25 Mar 2019, 13:29
Re: ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
Hallo Frank,
vielen Dank fuer die Rueckmeldung. Das ist eine Loesung, die wir aktuell in Betracht ziehen. Alternativ werden wir Vorgaben machen, dass an dem einen Port ein anderer Addressraum zu nutzen ist.
Viele Gruesse
Christian
vielen Dank fuer die Rueckmeldung. Das ist eine Loesung, die wir aktuell in Betracht ziehen. Alternativ werden wir Vorgaben machen, dass an dem einen Port ein anderer Addressraum zu nutzen ist.
Viele Gruesse
Christian
Re: ETH A + B im selben IP-Adressbereich, ETH B nicht mehr erreichbar
Hallo Christian,
ein anderer Adressraum geht natürlich auch !
Liebe Grüße
Frank
ein anderer Adressraum geht natürlich auch !
Liebe Grüße
Frank