Oct 02, 2020, updated at 18:14:18 (UTC)

2367

Raspberry mit ntopng nicht mehr erreichbar

Hallo zusammen,

ich habe mir einen neuen Raspberry 4 geholt, um dort mit ntopng den Netzwerktraffic von einer von mir betreuten Einrichtung zu analysieren. Leider ist der RPI nicht mehr erreichbar, sobald ich das LAN-Kabel bei eth0 (für ntopng) einstecke. Sobald ich das Kabel entferne, ist der Raspberry wieder erreichbar.

Hier habe ich einen Ping von meinem Notebook Richtung RPi (192.168.10.12) laufen lassen:

Antwort von 192.168.10.12: Bytes=32 Zeit=6ms TTL=64     
Antwort von 192.168.10.12: Bytes=32 Zeit=3ms TTL=64
Antwort von 192.168.10.12: Bytes=32 Zeit=6ms TTL=64
Zeitüberschreitung der Anforderung.                   => Lankabel auf eth0 (Port für ntopng) wurde eingesteckt
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.10.25: Zielhost nicht erreichbar. => Lankabel auf eth0 wurde wieder entfernt
Antwort von 192.168.10.12: Bytes=32 Zeit=1ms TTL=64
Antwort von 192.168.10.12: Bytes=32 Zeit<1ms TTL=64
Antwort von 192.168.10.12: Bytes=32 Zeit<1ms TTL=64

In meinem Netzwerk habe ich 6 Vlans; alle Hardware Geräte befinden sich im Vlan 1 im Netz 192.168.10.1/24. Vereinfacht sieht mein Netzwerk so aus:

Router (Trunk Port) -------- (Trunk Port 1) Switch 1 (Trunk Port 6) ------- (Trunk Port 6) Switch 2
´´´´´´´´´´´´´´´´´´´´´´´´´´(Port 4: Mirror von Port 1) ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´(Port2 Access mode)
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´| ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ |
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´| ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ |
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´(eth0) ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´ |
´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´Raspberry Pi (eth1) <---------------------------------------|

Am Switch 1 ist Port 1 die Verbindung zum Router. Diese Verbindung wird im Switch 1 auf Port 4 gespiegelt:

Gespiegelt wird eingehender und ausgehender Traffic.
=> Ich stelle an dieser Stelle bereits Komplikationen im Netzwerk fest; Speed ist DEUTLICH langsamer und Verbindungen brechen teilweise ab.

Auf dem Raspberry ist eth0 der fest verbaute Eth-Eingang und eth1 ist ein USB-LAN-Adapater.
eth0 ist im Promiscuous Mode und ist für den Eingang zu ntopng gedacht. eth1 hat via dhcpcd.conf eine feste IP damit der Raspberry im Netzwerk erreichbar ist.
ifconfig:

pi@raspberrypi-ntopng:~ $ ifconfig
eth0: flags=4355<UP,BROADCAST,PROMISC,MULTICAST>  mtu 1500
        ether dc:a6:32:bb:be:d8  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.12  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::604c:4b13:efe2:6135  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4c:68:00:bb  txqueuelen 1000  (Ethernet)
        RX packets 15959  bytes 2564050 (2.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3179  bytes 196612 (192.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

=> Aktuell ist bei eth0 kein Kabel eingesteckt da sonst der RPi wieder nicht mehr erreichbar ist.
=> Wenn das Kabel bei eth0 mit Mirror-Port 4 am Switch 1 verbunden wird, ist kein Client im Netzwerk mehr mit dem Internet verbunden. Mit meinem Notebook kann ich zwar noch Geräte wie dem Router erreichen und der ist theoretisch online, aber ich kann keine Webseite mehr erreichen.

In der Datei dhcpcd.conf hab ich lediglich die folgenden Zeilen für eth1 hinzugefügt:

interface eth1
static ip_address=192.168.10.12/24
static routers=192.168.10.1
static domain_name_servers=192.168.10.11 1.1.1.1

Falls nötig, stelle ich auch gerne den kompletten Inhalt der dhcpcd.conf sowie die Konfigurationsdatei von ntopng.conf zur Verfügung.

Hat jemand vielleicht eine Idee warum der Raspberry nicht mehr erreichbar ist, sobald bei eth0 das Lan-Kabel angeschlossen wird?

Please also mark the comments that contributed to the solution of the article

Content-Key: 609539

Url: https://administrator.de/contentid/609539

Printed on: April 27, 2024 at 01:04 o'clock

5 Comments

Latest comment

Vereinfacht sieht mein Netzwerk so aus:

Sorry, aber diese wirren ASCII Hieroglyphen kann kein Mensch erkennen, geschweige denn verstehen wie das Netz aussieht.

Kann es sein das dein eth0 und dein WLAN Adapter wlan0 des RasPis gleichzeitig im gleichen IP Netz sind ?? Das wäre ein möglicher Grund.
Hilfreich wäre noch zu wissen wie der eth0 Port in der dhcpcd.conf konfiguriert ist ?!
Weitere Infos zu dem Thema findest du auch hier.

Hi aqui,
danke für deine Antwort! Ja, die Netzwerkskizze sieht vor allem im mobilen Modus blöd aus... Daher nun das doch das Bild:

Port 4 auf dem Switch Keller Main ist außerdem analog zu Port 1 im Trunk Mode & tagged only.
Gibt im Netzwerk noch weitere Komponenten (Switche, AccessPoints, WLAN-Controller etc.), die dürften hier aber keine Rolle spielen.

Zitat von @aqui:
Kann es sein das dein eth0 und dein WLAN Adapter wlan0 des RasPis gleichzeitig im gleichen IP Netz sind ?? Das wäre ein möglicher Grund.

Das dürfte aus meiner Sicht nicht der Fall sein. Ich habe den RasPi nicht ins WLAN eingebunden. Aktuell hat wlan0 auch keine IP; siehe ifconfig:

pi@raspberrypi-ntopng:~ $ ifconfig
eth0: flags=4355<UP,BROADCAST,PROMISC,MULTICAST>  mtu 1500
        ether dc:a6:32:bb:be:d8  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.10.12  netmask 255.255.255.0  broadcast 192.168.10.255
        inet6 fe80::604c:4b13:efe2:6135  prefixlen 64  scopeid 0x20<link>
        ether 00:e0:4c:68:00:bb  txqueuelen 1000  (Ethernet)
        RX packets 178  bytes 25523 (24.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 208  bytes 19503 (19.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 7836  bytes 1163458 (1.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7836  bytes 1163458 (1.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether dc:a6:32:bb:be:d9  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Zitat von @aqui:
Hilfreich wäre noch zu wissen wie der eth0 Port in der dhcpcd.conf konfiguriert ist ?!

eth0 ist in der dhcpcd.conf gar nicht konfiguriert. Ich wusste hier auch gar nicht, was ich hier einstellen soll, da eht0 ja keine IP bekommen soll, sondern einfach nur den Traffic annehmen soll. Muss ich eventuell für den Port DHCP ausschalten?
Ich habe lediglich den Modus von eth0 auf den promiscuous mode umgestellt:

pi@raspberrypi-ntopng:~ $ netstat -i |grep eth0
eth0      1500        0      0      0 0             0      0      0      0 BMPU

Zitat von @aqui:
Weitere Infos zu dem Thema findest du auch hier.

Danke, da hatte ich schon mal einen Blick reingeworfen. Hab aber noch keine genauen Infos zur Konfiguration zu eth0 gefunden, auch in anderen Quellen nicht.

Port 4 auf dem Switch Keller Main ist außerdem analog zu Port 1 im Trunk Mode & tagged only.

tagged only ist vermutlich der Fehler !
Wenn eth0 auf dem physischen Interface die IP liegen hat oder als DHCP Client dort arbeitet erwartet das Interface natürlich immer UNtagged Pakete. Das physische Interface versteht immer nur UNtagged. Wenn der Switch aber einzig nur VLAN getaggte Pakete forwardet kann es dann auf dem physischen eth0 Interface niemals eine IP Verbindung geben, weder mit statische IP noch mit DHCP, das ist klar, denn alle Untagged Pakete die der RasPi an eth0 erwartet werden dann am Switch verworfen sowohl eingehend als auch ausgehend.
Wenn, dann müsste der VLAN Mode auf all stehen und relevant ist dann die PVID dieses Ports in welches VLAN der RasPi dann an eth0 arbeitet.

Hi Aqui,

ich vermute auch stark dass der Fehler nicht am RasPi liegt, sondern am Switch. Ich beobachte, dass mein Downloadspeed von 100 Mbit/s auf teils nur noch 3 Mbit/s sinkt und andere Geräte kaum noch erreichbar sind, sobald ich die Port-Mirroring-Funktion so aktiviere. Da steckte das Kabel auf Port 4 zum ntopng-Port vom RasPi noch gar nicht drin...

Ich habe hierzu auch einen Case beim Hersteller (D-Link) aufgemacht da mir dieses Verhalten sehr seltsam vorkommt. Da liegt für mich die Vermutung eines Bugs nahe.

Zitat von @aqui:
Wenn eth0 auf dem physischen Interface die IP liegen hat oder als DHCP Client dort arbeitet erwartet das Interface natürlich immer UNtagged Pakete.

Das ist für mich die Frage: Braucht eth0 eine IP Adresse? eth0 soll ja nur den Traffic analysieren und schauen, was in den VLANs abläuft. Wenn der RasPi nur mitliest, dann braucht es doch auch keine IP Adresse für diesen Port, da dieser ja nicht antworten soll bzw. auch nicht speziell erreichbar sein muss (dazu hab ich ja eth1).

Zitat von @aqui:
Das physische Interface versteht immer nur UNtagged.

Hm, dann sieht die Sache wohl anders aus. Durch untagged verliere ich allerdings auch die VLAN-Information und weiß nicht mehr, so welchem VLAN ein Paket gehört. Diese Info hätte ich in den Ntopng Analysen eigentlich gerne dabei. Muss ich also doch auf untagged setzen?

Zitat von @aqui:
Wenn der Switch aber einzig nur VLAN getaggte Pakete forwardet kann es dann auf dem physischen eth0 Interface niemals eine IP Verbindung geben, weder mit statische IP noch mit DHCP, das ist klar, denn alle Untagged Pakete die der RasPi an eth0 erwartet werden dann am Switch verworfen sowohl eingehend als auch ausgehend.

Also ohne IP Verbindung gibt es keinen eingehenden Traffic für ntopng? Ok, dann brauchts hier wohl doch den DHCP Mode und eine IP Adresse für eth0.

Zitat von @aqui:
Wenn, dann müsste der VLAN Mode auf all stehen und relevant ist dann die PVID dieses Ports in welches VLAN der RasPi dann an eth0 arbeitet.

Gut, dann würde ich mal PVID auf 1 setzen (ist mein Management VLAN). D-Link bietet hier einen "Hybrid Mode" an:

So könnte man es mal ausprobieren, oder?

Das ist für mich die Frage: Braucht eth0 eine IP Adresse?

Nein. Nur für die Analyse nicht, da reicht der Promiscous Mode aus. Fatal ist aber das du die Frames alle tagst auf dem Analyse Port. Eigentlich unsinnig und bewirkt vermutlich das der Port diese Frames durch die 802.1q VLAN Erweiterung dann nicht erkennt und als Frame Error verwirft. Das sollte man besser vorher testen.

Durch untagged verliere ich allerdings auch die VLAN-Information und weiß nicht mehr, so welchem VLAN ein Paket gehört.

Deshalb ja vorher immer wasserdicht austesten. Installiere dir mit apt install wireshark den Wireshark und hänge den mal an einen tagged Port. Wenn er dir die VLAN Tags anzeigt wie hier zu sehen:

Dann kann er auch im Promiscous Mode die Tags darstellen.

Also ohne IP Verbindung gibt es keinen eingehenden Traffic für ntopng?

Doch, das sollte für untagged Traffic problemlos klappen. Tagged musst du besser testen:
Netzwerk Management Server mit Raspberry Pi

So könnte man es mal ausprobieren, oder?

Ja, richtig. Das PVID VLAN 1 kommt dann dort untagged raus alle anderen VLANs tagged. Ist ein klassischer Trunk Port.

German Question Linux Network Linux