Bridge nicht erreichbar
Bridge nicht erreichbar
Hallo,
mein Szenario ist schnell erklärt. Ich habe 1 Router, 1 PC, 1 RPI - auf dem RPI hab ich mit brctl eine Netzwerkbrücke aufgebaut welche vom Router eine eigene IP bezogen hat. Das Netz dahinter ist im Subnetz.
Die Bridge verbindet etho0 mit einem virtuellen Port. An eth0 steckt die Verbindung zum Router.
In ifconfig bzw. ip a sieht alles gut aus, alle Interfaces 'up' und mit IP. Mein Problem ist nun dass ich den RPI nicht anpingen kann (weder die Brücke, noch eth0 oder den virtuellen Port). Der RPI kann auch nicht pingen, außer an sich selbst.
dhclient läuft und port_forwarding ist auch aktiviert
Ohne Brücke kann ich eth0 anpingen, ohne Probleme, aber mit Brücke ist der RPI garnicht zu gebrauchen
Hoffe ihr könnt mir helfen
Gruß
mein Szenario ist schnell erklärt. Ich habe 1 Router, 1 PC, 1 RPI - auf dem RPI hab ich mit brctl eine Netzwerkbrücke aufgebaut welche vom Router eine eigene IP bezogen hat. Das Netz dahinter ist im Subnetz.
Die Bridge verbindet etho0 mit einem virtuellen Port. An eth0 steckt die Verbindung zum Router.
In ifconfig bzw. ip a sieht alles gut aus, alle Interfaces 'up' und mit IP. Mein Problem ist nun dass ich den RPI nicht anpingen kann (weder die Brücke, noch eth0 oder den virtuellen Port). Der RPI kann auch nicht pingen, außer an sich selbst.
dhclient läuft und port_forwarding ist auch aktiviert
Ohne Brücke kann ich eth0 anpingen, ohne Probleme, aber mit Brücke ist der RPI garnicht zu gebrauchen
Hoffe ihr könnt mir helfen
Gruß
Re: Bridge nicht erreichbar
Per
/etc/network/interfaces
konfiguriert?
Diese Datei posten?
/etc/network/interfaces
konfiguriert?
Diese Datei posten?
?In ifconfig bzw. ip a sieht alles gut aus, alle Interfaces 'up' und mit IP.
mfg rendegast
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
-----------------------
Viel Eifer, viel Irrtum; weniger Eifer, weniger Irrtum; kein Eifer, kein Irrtum.
(Lin Yutang "Moment in Peking")
- heisenberg
- Beiträge: 3561
- Registriert: 04.06.2015 01:17:27
- Lizenz eigener Beiträge: MIT Lizenz
Re: Bridge nicht erreichbar
Prüfe doch mal folgendes, und stelle die Ausgaben hier rein(Code Tags bitte):
- Ausgabe ip a von PC und Raspi
- Ausgabe brctl show vom Raspi
- IP+Netzmaske vom internen Netzwerkinterface des Routers
Jede Rohheit hat ihren Ursprung in einer Schwäche.
Re: Bridge nicht erreichbar
Wenn ich es richtig verstanden habe, ist der nicht pingbare RPI als Bridge konfiguriert. Eine Bridge arbeitet ausschließlich auf OSI Layer 2 (Ethernet/WLAN) und interessiert sich erst mal nicht für IP-Protokoll. Transparent für IP. Genau wie ein Switch oder reiner WLAN-Accesspoint. Beide benoetigen für ihre Funktion gar keine eigene IP-Adr. Entweder ist ein zusätzlicher (logischer) IP-Managementzugang zu konfigurieren oder der RPI als Router zu konfigurieren, dann wäre jedes Interface mit IP-Adresse versehen und pingbar und das Gerät inband erreichbar. Sowie per Loopback-Interface. Vlt. funktioniert das mit Loopback auch bei Bridges.
DHCP (inband) ist auf einer Bridge oder WLAN-Accesspoint nicht sinnvoll, bei einem Switch sieht das jeder sofort ein, einen Switch kann man jedoch als Multiport-Bridge betrachten. Für Managemenzugang (outband) muss man sich was einfallen lassen, kenne mich dazu aber nur bei Lancom und Cisco aus. Dafür wäre dann eine feste IP (evtl.auch per DHCP-MAC-IP-Zuordnung) sinnvoll. Bei Switches/Accesspoints/Bridges nutzt man unterschiedliche VLANs für Management (terminiert)und Nutzdaten (durchgeleitet), bei Routern erfolgt das inband per Loopback-Interface oder über die Interface-Adressen.
Also du brauchst fuer Bridge-Management auf einem phys. Interface 2 logische, eines inband für Brueckenfunktion mit einem anderen physischen und ein terminierendes (outband) mit IP-Adr. für Management. Portforwarding für NAT auf Bridge fuer Management? Wäre nicht sinnvoll - ausser evtl. fuer Fernmanagement.
https://learningnetwork.cisco.com/thread/30501
Loopback-If unter IPv4: Netzmaske /32 sinnvoll und üblich.
DHCP (inband) ist auf einer Bridge oder WLAN-Accesspoint nicht sinnvoll, bei einem Switch sieht das jeder sofort ein, einen Switch kann man jedoch als Multiport-Bridge betrachten. Für Managemenzugang (outband) muss man sich was einfallen lassen, kenne mich dazu aber nur bei Lancom und Cisco aus. Dafür wäre dann eine feste IP (evtl.auch per DHCP-MAC-IP-Zuordnung) sinnvoll. Bei Switches/Accesspoints/Bridges nutzt man unterschiedliche VLANs für Management (terminiert)und Nutzdaten (durchgeleitet), bei Routern erfolgt das inband per Loopback-Interface oder über die Interface-Adressen.
Also du brauchst fuer Bridge-Management auf einem phys. Interface 2 logische, eines inband für Brueckenfunktion mit einem anderen physischen und ein terminierendes (outband) mit IP-Adr. für Management. Portforwarding für NAT auf Bridge fuer Management? Wäre nicht sinnvoll - ausser evtl. fuer Fernmanagement.
https://learningnetwork.cisco.com/thread/30501
Loopback-If unter IPv4: Netzmaske /32 sinnvoll und üblich.
Re: Bridge nicht erreichbar
Es ist durchaus üblich unter Linux der Bridge selbst eine IP zu geben.
Üblicher als Loopback-Adressen würd' ich mal sagen.
Aus der Beschreibung heraus vermute ich, daß sowohl der Bridge als auch dem eth0 eine IP verpasst wurde.
Dies ist eher unüblich, die IP bekommt nur das Bridge-interface,
vgl. auch https://wiki.debian.org/BridgeNetworkConnections
Üblicher als Loopback-Adressen würd' ich mal sagen.
Aus der Beschreibung heraus vermute ich, daß sowohl der Bridge als auch dem eth0 eine IP verpasst wurde.
Dies ist eher unüblich, die IP bekommt nur das Bridge-interface,
vgl. auch https://wiki.debian.org/BridgeNetworkConnections
Re: Bridge nicht erreichbar
dufty2 hat bezueglich Debian (sowie Ubuntu) vollkommen Recht, habe mich daraufhin auch belesen, hier noch auf deutsch:
https://wiki.ubuntuusers.de/Netzwerkbrücke/
Also Bridge mit IP-Adr. und "stinknormaler" Netzmaske.
(Zum auf der Bridge laufenden Debian wird wohl einfach inband mit gebrückt. Na ja, sicherheitstechnisch Geschmackssache - zumindest ohne weitere Vorkehrungen. Innerhalb eines Homenetzwerks ohne WLAN belanglos und bequem.)
https://wiki.ubuntuusers.de/Netzwerkbrücke/
Also Bridge mit IP-Adr. und "stinknormaler" Netzmaske.
(Zum auf der Bridge laufenden Debian wird wohl einfach inband mit gebrückt. Na ja, sicherheitstechnisch Geschmackssache - zumindest ohne weitere Vorkehrungen. Innerhalb eines Homenetzwerks ohne WLAN belanglos und bequem.)
Re: Bridge nicht erreichbar
Ich hatte auch gelesen dass Netzwerkbrücken auf Layer 2 arbeiten (also MAC), dachte also es würde somit mit ping nicht funktionieren.
Nachdem ich etwas probiert hatte und lediglich der Brücke eine IP gegeben hab (ja, ich hatte initial auch den beiden Ports eine IP verpasst), konnte ich auch die Brücke anpingen. Nun gibt es also lediglich EINE IP für den RPI, die IP für die Netzwerkbrücke.
Obwohl alle Geräte bei diesem Szenario nun in einem Netz waren, gehe ich davon aus, dass es auch mit einem Subnetz funktioniert - Tests folgen dafür muss dann aber NAT genutzt werden.
Kurz und knapp, ich habe also nachdem ich die Brücke mit brctl erstellt habe eine flush auf die verbundenen Ports gemacht und es lief
Auf ins Subnet
Nachdem ich etwas probiert hatte und lediglich der Brücke eine IP gegeben hab (ja, ich hatte initial auch den beiden Ports eine IP verpasst), konnte ich auch die Brücke anpingen. Nun gibt es also lediglich EINE IP für den RPI, die IP für die Netzwerkbrücke.
Obwohl alle Geräte bei diesem Szenario nun in einem Netz waren, gehe ich davon aus, dass es auch mit einem Subnetz funktioniert - Tests folgen dafür muss dann aber NAT genutzt werden.
Kurz und knapp, ich habe also nachdem ich die Brücke mit brctl erstellt habe eine flush auf die verbundenen Ports gemacht und es lief
Auf ins Subnet
Re: Bridge nicht erreichbar
Nein, wenn du separate Subnetze willst, muß der Raspi als Router konfiguriert werden und nicht als Bridge.qnavwhat hat geschrieben:gehe ich davon aus, dass es auch mit einem Subnetz funktioniert
Re: Bridge nicht erreichbar
Entweder wie MSfree schrieb oder:
Nutzung verschiedener VLANs auf (Mulitiport-) Bridge und Routing der VLANs mit unterschiedlichen Subnets durch externen, VLAN-faehigen Router (evtl. extra VLAN mit extra Subnet für Bridge-Management / Rasp mit konfigurierter Bridge)
https://wiki.debian.org/BridgeNetworkCo ... with_VLANs
(Hat aber wenig Sinn für deine wenigen Bruecken-Ports - hast ja nur eth0 und wlan0 - ausser du willst den Management-Zugang zum Rasp von den Nutzdaten derart trennen, dass du z. B. mit Accesslist dazwischen routest. Wäre sinnvoll für Absicherung eines vorher nur gebridgten WLAN-Zuganges. Vmtl. ist jedoch eine Konfiguration als Router für dich am sinnvollsten und einfachsten. In der letzten (?) c't war ein interessantes Routing-Projekt mit Sniffing und IPv6.)
nicht sinnvoll:
unterschiedliche, nur gebridgte Subnets: Wäre das Gleiche wie mehrere PCs mit unterschiedlichen, auf PCs konfigurierten Subnets in einem einzigen LAN-Segment.
Nutzung verschiedener VLANs auf (Mulitiport-) Bridge und Routing der VLANs mit unterschiedlichen Subnets durch externen, VLAN-faehigen Router (evtl. extra VLAN mit extra Subnet für Bridge-Management / Rasp mit konfigurierter Bridge)
https://wiki.debian.org/BridgeNetworkCo ... with_VLANs
(Hat aber wenig Sinn für deine wenigen Bruecken-Ports - hast ja nur eth0 und wlan0 - ausser du willst den Management-Zugang zum Rasp von den Nutzdaten derart trennen, dass du z. B. mit Accesslist dazwischen routest. Wäre sinnvoll für Absicherung eines vorher nur gebridgten WLAN-Zuganges. Vmtl. ist jedoch eine Konfiguration als Router für dich am sinnvollsten und einfachsten. In der letzten (?) c't war ein interessantes Routing-Projekt mit Sniffing und IPv6.)
nicht sinnvoll:
unterschiedliche, nur gebridgte Subnets: Wäre das Gleiche wie mehrere PCs mit unterschiedlichen, auf PCs konfigurierten Subnets in einem einzigen LAN-Segment.
Re: Bridge nicht erreichbar
Mmmh, also streng genommen wissen wir nichts von einem "wlan0".
Er (oder sie) schreibt nur von einem "virtuellen port" (was immer auch das sein soll).
Und der PC kann auch direkt am Router hängen, muss nicht notwendigerweise "hinter" dem Raspi stehen.
Und bevor wir uns mit VLANs & Co hier beschäftigen, sollten wir es lieber möglichst einfach halten.
Oder nicht?
Er (oder sie) schreibt nur von einem "virtuellen port" (was immer auch das sein soll).
Und der PC kann auch direkt am Router hängen, muss nicht notwendigerweise "hinter" dem Raspi stehen.
Und bevor wir uns mit VLANs & Co hier beschäftigen, sollten wir es lieber möglichst einfach halten.
Oder nicht?
Re: Bridge nicht erreichbar
Wenn dann sinnvoll, Router ist schon okay. Sollte der TE aus meiner AW erkennen. Der Raspi hat doch WLAN?!qnavwhat hat geschrieben: Auf ins Subnet
Re: Bridge nicht erreichbar
Oh na das gestaltet sich doch schwieriger als gedacht.
Zunächst, ich habe ein Raspi3 und da ist wlan sogar direkt mit bei.
Mein Ziel ist es den (bzw dann die) Raspi etwas abgekapselt vom restlichen Netz zu betreiben, sprich in einem Subnet. Die Erkenntnis über die Bridge ist zwar gut aber scheint nicht weiter relevant zu sein für das was ich möchte. Am einfachsten wäre sicher einen Router dazwischen zu setzen oder gar den Raspi als Router zu konfigurieren (dass andere Raspi's im Subnet mit dem PC kommunizieren können).
In die VLAN Sache les ich mich mal rein, vllt hilft mir das weiter
Zunächst, ich habe ein Raspi3 und da ist wlan sogar direkt mit bei.
Mein Ziel ist es den (bzw dann die) Raspi etwas abgekapselt vom restlichen Netz zu betreiben, sprich in einem Subnet. Die Erkenntnis über die Bridge ist zwar gut aber scheint nicht weiter relevant zu sein für das was ich möchte. Am einfachsten wäre sicher einen Router dazwischen zu setzen oder gar den Raspi als Router zu konfigurieren (dass andere Raspi's im Subnet mit dem PC kommunizieren können).
In die VLAN Sache les ich mich mal rein, vllt hilft mir das weiter
Re: Bridge nicht erreichbar
Eine Trennung deiner Raspis vom restlichen Netz sollte dein vorhandener Router machen - oder ein Raspi, der als Router konfiguriert wird. Letzterer hat aber wohl nur 2 phys. Interfaces, WLAN und Ethernet.
VLANs brauchst du dann, um auf einem physischen Port (Trunk) logische Trennungen für mehrere physische Accessports an Bridges oder Switches oder Accesspoints vorzunehmen. Um diese auf einem Router (restriktiv) zu verbinden. Ich empfehle, die VLAN-Routing-Geschichte erst mal konzeptionell zu recherchieren (debian-unspezifisch). Z. B.
http://www.dell.com/downloads/global/pr ... ote_38.pdf
Selbst bei einem reinen Bastelprojekt ist es gut, wenn man die zu erfüllende Aufgabe für sich und andere definiert, vielleicht so: Raspi als
- Luxus-WLAN-Accesspoint mit einem Ethernet-VLAN-Trunk-Port und unterschiedlich getaggten VLANs für Management, Eigen- und Gast-WLAN, die dann ein anderer, VLAN-fähiger Router (Raspi) erkennen und restriktiv verbinden muss
- Router mit einem Ethernet-VLAN-Trunk-Port der zwischen unterschiedlich getaggten VLANs routen kann
- WLAN-Router ohne VLANs, Trennung WLAN und Gast-WLAN über Accesslists
- einfacher WLAN-Accesspoint
- oder oder
Ich kann dir aber sagen, dass VLANs privat kaum verwendet werden, das "erschlägt" man einfach über physich getrennte Router-Ports - notfalls mit mehreren Switches bei mehreren Router-Ports, evtl. zusätzlicher Accesspoints, wenn der Router keine Trennung Gast-Eigen-WLAN kann..
VLANs brauchst du dann, um auf einem physischen Port (Trunk) logische Trennungen für mehrere physische Accessports an Bridges oder Switches oder Accesspoints vorzunehmen. Um diese auf einem Router (restriktiv) zu verbinden. Ich empfehle, die VLAN-Routing-Geschichte erst mal konzeptionell zu recherchieren (debian-unspezifisch). Z. B.
http://www.dell.com/downloads/global/pr ... ote_38.pdf
Selbst bei einem reinen Bastelprojekt ist es gut, wenn man die zu erfüllende Aufgabe für sich und andere definiert, vielleicht so: Raspi als
- Luxus-WLAN-Accesspoint mit einem Ethernet-VLAN-Trunk-Port und unterschiedlich getaggten VLANs für Management, Eigen- und Gast-WLAN, die dann ein anderer, VLAN-fähiger Router (Raspi) erkennen und restriktiv verbinden muss
- Router mit einem Ethernet-VLAN-Trunk-Port der zwischen unterschiedlich getaggten VLANs routen kann
- WLAN-Router ohne VLANs, Trennung WLAN und Gast-WLAN über Accesslists
- einfacher WLAN-Accesspoint
- oder oder
Ich kann dir aber sagen, dass VLANs privat kaum verwendet werden, das "erschlägt" man einfach über physich getrennte Router-Ports - notfalls mit mehreren Switches bei mehreren Router-Ports, evtl. zusätzlicher Accesspoints, wenn der Router keine Trennung Gast-Eigen-WLAN kann..
Zuletzt geändert von BenutzerGa4gooPh am 25.05.2016 19:36:13, insgesamt 1-mal geändert.
Re: Bridge nicht erreichbar
VTP wird nicht klappen, da Cisco-eigen.
Unter Linux müsste man dafür Multiple VLAN Registration Protocol (MVRP) nehmen.
Aber bei diesem Netzwerk ein bisschen overkill
Unter Linux müsste man dafür Multiple VLAN Registration Protocol (MVRP) nehmen.
Aber bei diesem Netzwerk ein bisschen overkill
Re: Bridge nicht erreichbar
@dufty2:
Oh stimmt, nach IEEE 802.1Q wurde das VLAN-Tagging (endlich,) standardisiert. Bin schon eine alte, proprietäre Saeckin. Wie nennt man das Protokoll an sich jetzt unter Netzwerkern kurz und herstelleruebergreifend? "Tagged Frames nach IEEE 802.1Q" erscheint mir zu unhandlich/unmundlich - müsste aber sinngemäß VTP entsprechen. (Untagged VLANs wären reine Ethernet-Frames ausserhalb eines Switches. Tagged VLANs betreffen wohl mehr das Konzept, dazu gehört nur u. a. das Protokoll.)
Na ich korrigiere mal meinen letzten Beitrag "herstellerübergreifend".
Basteln und Lernen ist doch kein Overkill, bei Dauerbetrieb sieht's anders aus.
Oh stimmt, nach IEEE 802.1Q wurde das VLAN-Tagging (endlich,) standardisiert. Bin schon eine alte, proprietäre Saeckin. Wie nennt man das Protokoll an sich jetzt unter Netzwerkern kurz und herstelleruebergreifend? "Tagged Frames nach IEEE 802.1Q" erscheint mir zu unhandlich/unmundlich - müsste aber sinngemäß VTP entsprechen. (Untagged VLANs wären reine Ethernet-Frames ausserhalb eines Switches. Tagged VLANs betreffen wohl mehr das Konzept, dazu gehört nur u. a. das Protokoll.)
Na ich korrigiere mal meinen letzten Beitrag "herstellerübergreifend".
Basteln und Lernen ist doch kein Overkill, bei Dauerbetrieb sieht's anders aus.
Re: Bridge nicht erreichbar
VLAN Trunking Protocol (VTP) ist zum Managen von zig VLANs resp. Switchen gedacht.
Hat man einen trunk mit mehreren (getaggten) VLANs spricht man einfach von ".1q" (dot-one-q).
Vielleicht verrät uns qnavwhat noch, was er für einen Router hat, dann müssen wir nicht über mögliche enterprise-features rätseln
Hat man einen trunk mit mehreren (getaggten) VLANs spricht man einfach von ".1q" (dot-one-q).
Vielleicht verrät uns qnavwhat noch, was er für einen Router hat, dann müssen wir nicht über mögliche enterprise-features rätseln
Re: Bridge nicht erreichbar
dufty2 hat geschrieben:Vielleicht verrät uns qnavwhat noch, was er für einen Router hat, dann müssen wir nicht über mögliche enterprise-features rätseln
Das Bridging-Problem ist eh gelöst, neuer Thread mit neuer Projektbeschreibung?