Netzwerk Topologie Erkennung

[Lolek]

Hallo Leuts,

kennt jemand von euch eine Möglichkeit wie man Netzwerkgeräte auf Layer 2 im Netzwerk finden kann?

Ich möchte gern wissen, ob im Netzwerk irgendwo soho switche oder hubs angeschlossen sind. Gibt es eine Möglichkeit solche Geräte zu finden?

Danke für eure Antworten.

[uname]

Du könntest mal lldpd installieren und starten.

Code: Alles auswählen

service lldpd start

und dann mal schauen was angezeigt wird:

Code: Alles auswählen

lldpctl 
-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------

Bei mir wird nichts angezeigt. Leider weiß ich nicht ob es dein Problem lösen kann. Suche nach entsprechender Dokumentation für lldp (Link Layer Discovery Protocol). Vielleicht liege ich aber vollkommen falsch.

[dufty2]

Naja, Debian hat ja die "tolle" Eigenschaft, Services sofort beim Installieren zu starten, sodaß man sich ein

Code: Alles auswählen

systemctl start lldpd.service

gleich sparen kann
Da die Gegenstelle(n) auch lldp (oder verwandte Protokolle wie CDP) haben müssen, wird in einem SOHO der Erfolg recht mager sein.

Ein

Code: Alles auswählen

$ ip n

zeigt Dir schon mal Dein Default-Gateway und nun kann man mittels nmap (diverse Optionen) sein Netzwerk durch-scannen.
Einen hub 2016 noch anzutreffen wird möglicherweise eher selten der Fall sein.
Die Art und Topologie der Switche zu bestimmen dürfte aufgrund der geringen Latenzen schwierig sein.
Und die "10-Euro-Switche" haben m.W. nicht mal eine MAC-Adresse.

[BenutzerGa4gooPh]

Arp koennte dein Freund werden:
http://www.problem-hilfe.de/linux/h/Netzwerk/arp.html
http://linux-ip.net/html/ether-arp.html
Des Weiteren existieren verschiedene "Netzwerk/Network-Sniffer", die sich leicht durch Googeln der vorgenannten Stichworte finden lassen. Persoenlich kenne ich nur Fing für Android als WLAN- und Port-Sniffer - neben MACs und IPs - um mein eigenes Netz ab und an zu kontrollieren.

Switches besitzen auf jedem Port eigene, unterschiedliche und damit der Portanzahl entsprechend viele MAC-Adressen (jedoch keine IPs - ausser evtl. "künstliche" für das Management) und arbeiten auf OSI-Layer 2 genau wie Bridges, Modems, Accesspoints. Erst Router und Endgeräte interessieren sich für das IP-Protokoll.
https://de.m.wikipedia.org/wiki/Switch_ ... rktechnik)
Über die Ausnahmen kann man streiten oder sie einfach Routern zuordnen.

Hubs wiederum sind rein elektrische "Sternverteiler" eines Bussystem (Ethernet) auf OSI-Layer 1 und genauso unsichtbar auf höheren Ebenen wie Netzwerkkabel. Suche demzufolge ausschliesslich mit rein natürlichen Sinnesorganen.

Früher, vor den Hubs, gab es sog. Vampirstecker fur Yellow Cable. Kenne ich nur vom Hoerensagen, untermauert aber meine Aussage vom mittlerweile gluecklicherweise unsichtbarem Ethernet-Bussystem. Auch die Notwendigkeit von ARP ergibt sich aus der BUS-Struktur.

[mat6937]

... eine Möglichkeit wie man Netzwerkgeräte auf Layer 2 im Netzwerk finden kann?

Evtl. auch mit:

Code: Alles auswählen

arp-scan --localnet

versuchen.

EDIT:

Mit arp-scan werden im aktuellen Subnetz, broadcast-arp-requests (mit dem arp-Protokoll 0x0806) an alle IP-Adressen des aktuellen (d. h. aus dem arp-scan, gestartet wird) Subnetzes gesendet. Z. B. hier eine (die letzte) der 256 Anfragen:

Code: Alles auswählen

12:04:47.688317 ##:##:##:##:ca:## > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.178.255 tell 192.168.178.26, length 28

[BenutzerGa4gooPh]

Ich habe meinen Beitrag überschlafen, mit dem Ergebnis, dass im ARP-Cache m. E. nur die Ergebnisse einer erfolgreichen Auflösung (positive Antwort auf Broadcast) IP > MAC-Adresse stehen. Diese Auflösung sollte demzufolge nur für die IP-Management-Adresse eines Switches klappen. Und genau die hat nicht jedes unmanagebare Billigteil, ausserdem ist diese nicht in jedem Fall erreichbar (VLAN-Trennung Produktiv- und Management-Netz z. B.).

Des Weiteren werden einfache Netzwerkscanner/Portcanner auf OSI-Layer 2 keine Ergebnisse bringen. Nun kenne ich Wireshark nur vom Hörensagen, aber dort koennte ich mir vorstellen, der kann neben IP-Paketen auch Ethernet-Frames analysieren. Also testen.

Eine Methode, die auf jeden Fall klappt, selbst (früher) ab und an durchgeführt, aber aus ganz anderen Gründen:
Du sprichst sicher von einem Firmennetzwerk (oder oeffentlichem), im eigenen würdest du die eingesetzten Geräte ja wohl kennen. Also beschaffe (auf Firmenkosten) einen guten, management-faehigen Switch, Port-Anzahl unwichtig. Mit dessen eingebauten Management analysierst du das Spannung Tree Protocol, Status etc. Das Spanning Tree Protocol dient zur Auflösung physischer Wegeredundanzen (Schleifen) und muss dazu jeden Switch einbeziehen, egal ob managebar oder nicht. Allerdings nur im eigenem Routing-Segment (IP-Subnetz).
https://de.m.wikipedia.org/wiki/Spanning_Tree_Protocol
Diese Analyse ist demnach fuer jedes Routing -Segment und fuer jedes VLAN einzeln zu tun, beides sind Grenzen einer Broadcast Domain.

Ich würde auch kein Consumer-Geraet in Erwägung ziehen, sondern eines, dass für die Nutzung mit einem professionellem Managementsystem geeignet ist, wobei man das Managementsystem an sich nicht benötigt, die im Switch implementierten Funktionen sind ausreichend - wenn auch nicht so bunt. Falls du Glück hast, kennt trotzdem jemand Consumer-Geraete, die das auch beherrschen.

Vielleicht fällt jemand noch was Besseres ein, interessiert mich auch selbst. Puh, jetzt kann ich endlich wieder ruhig schlafen.

[dufty2]

Das Spanning Tree Protocol dient zur Auflösung physischer Wegeredundanzen (Schleifen) und muss dazu jeden Switch einbeziehen, egal ob managebar oder nicht.

Diese Billig-Switche haben auch kein STP (deswegen sind sie ja so billig )
U. a. benutzt man ja an seinen z. B. Cisco-Teilen
port-security
bpduguard
dynamic arp inspection
um diese "kleinen Raupauken" auszuschliessen.

[BenutzerGa4gooPh]

Switches ohne STP? Beim Stecken eines redundanten Kabels (Schleife) würde es ja sofort zu Rahmen-Doppelung kommen. Du meinst auch bestimmt keine Hubs mit den Billigteilen?

Ansonsten kann ich nur sagen, die Welt verändert sich, heute zum Schlechteren, morgen zum Schlimmeren.
(Deshalb habe ich früher auch mit Cisco gearbeitet. )

[dufty2]

Switches ohne STP? Beim Stecken eines redundanten Kabels (Schleife) würde es ja sofort zu Rahmen-Doppelung kommen. Du meinst auch bestimmt keine Hubs mit den Billigteilen?

Nö, ich meine sowas wie den (un-managed) 5-port Gigabit Switch Netgear GS105 für 23 € auf amazon.de

[BenutzerGa4gooPh]

Korrekt, mal Datenblatt durchgeschaut, einige aus der 105er Serie haben keine "Schleifenerkennung".
Das mit der Welt habe ich schon gesagt ....

Wird dem TE aber nicht helfen. Einige der nachfolgend beschriebenen Dinge, helfen auf jeden Fall bei der Auffindung:

"Sind Empfangs- und Zielsegment identisch, muss das Frame nicht weitergeleitet werden, da die Kommunikation ohne Switch im Segment selbst stattfinden kann." Daraus kann man folgern, wenn das passiert, ist en Switch im fraglichen Segment. Also Network Analyzer.

Ein Switch begrenzt eine Collision Domain. Kann man ebenfalls zur Erkennung nutzen: Kollisionen hervorrufen und ihr Fehlen am anderen Ende einer Leitung zeugt vom Vorhandensein eines Switches. Das geht technisch recht einfach.

https://de.m.wikipedia.org/wiki/Switch_ ... rktechnik)
Weitere, in Fremdnetzen illegale Manipulationen sind ebenfalls aufgeführt, während o. g. Methoden ein Netzwerk m. E. nicht stoeren.

[dufty2]

Ein Switch begrenzt eine Collision Domain. Kann man ebenfalls zur Erkennung nutzen: Kollisionen hervorrufen und ihr Fehlen am anderen Ende einer Leitung zeugt vom Vorhandensein eines Switches. Das geht technisch recht einfach.

Ach ja? Wenn das so einfach geht, dann verrat' doch mal wie genau?

Wir leben im Vollduplex-Zeitalter, da gibt es so gut wie keine Kollisionen mehr und HUBs verwendet auch (fast) kein mensch mehr (wir sprechen nicht von USB-Hubs).

[BenutzerGa4gooPh]

Ach ja? Wenn das so einfach geht, dann verrat' doch mal wie genau?

Ein PC mit 2 Netzwerkkarten angeschlossen an einen Hub - und wenn es ein altes Gerät ist - erzeugt zumindest einige Kollisionen auf Layer 2, auch wenn auf Layer 3 nur eine Route gilt. Man kann durchaus 2 verschiedene Routen / ping auf 2 verschiedene Netzwerke nutzen. Wegen mir auch 2 PCs mit je 1 Netzwerkkarte. Netzwerkarten lassen sich heute noch halbduplex betreiben.

Etliche Netzwerkkomponenten, wie z. B. Switches und Netzwerkkarten zeigen Kollisionen am anderen Ende sogar mit LEDs an. Bei entsprechender Einstellung reagieren sie durch automatisches Umschalten in Halbduplex darauf. Elegantere Anzeige natürlich mit Software, z. B.

Code: Alles auswählen

ifconfig eth0
oder 
ethtool eth0

Ein eventuell zwischengeschalteter Switch gibt die erzeugten Kollisionen nicht über andere Ports weiter. Also Switch erkannt. Eine ausschließliche Analyse des Segmentes (also ohne Manipulation mit Hub und 2 Netzwerkkarten) auf Halbduplex/Kollisionen zeigt das Vorhandensein eines Hubs - leider nur bei mindestens 2 daran aktiven Netzwerkkarten - was aber wohl der Sinn eines Hubs ist. Man muss nur den richtigen Zeitpunkt erwischen, z. B. durch Daueranalyse/Aufzeichnung.

Des Weiteren hatte der TE explizit nach Hubs gefragt - also sollte es diese Gerätschaften (zugegeben selten) noch geben, wegen mir auch im Antikhandel erworben oder aus einer doppelten Netzwerkdose mit Netzwerkkabel (davon geschnittenesPigtail) als Uplink selbst gebaut. Beides ist im Baumarkt erhältlich. Ethernet ist nun mal ein einfaches Bussystem - auch wenn man es nicht mehr sieht. Es gibt natürlich professionelleTrafficgeneratoren mit Rahmen- und Paketmanipulationen - sicherlich entsprechende debian-Pakete zum "Eigenbau" selbiger.

Damit müsste die Aufgabe von dufty2 und dem TE erfüllt sein???

Code: Alles auswählen

arp-scan --localnet

zeigt nur erfolgreiche Zuordnung von IP-MAC-Adressen (Antworten), also keine unmanagebaren Switches, Hubs etc. Gerade mal probiert.

[Lolek]

Hallo an alle und danke für die zahlreichen Antworten.

Mein Ziel ist es eigentlich eben diese 15 euro Geräte zu finden. Ich habe hier ein Netzwerk übernommen das sich über mehrere Gebäude erstreckt und nicht richtig funktioniert. Auf meinen Rundgängen durch die Gebäude habe ich echt gestaunt hinter wie vielen Büromöbeln man Netzwerkkomponenten verstecken kann. .

LLDP habe ich schon versucht, hatte aber nicht den gewünschten Erfolg. Man findet mit LLDP nur die Switche die eh im Zugriff des Admins stehen.

Der Ansatz von Jana66 das Problem über das spanning tree Protokoll anzugehen erscheint mir auch als denkbar.

Ich befürchte nur die Turnschuharbeit und einige Anrufe das etwas nicht funktioniert werden mir nicht erspart bleiben.

Danke nochmal für eure Tipps.

[BenutzerGa4gooPh]

dufty2s Einwand bezueglich STP erschien mir aber sehr berechtigt - wenn auch neu für mich!

Um ausschließlich die "besseren" Switches zu lokalisieren, würde ich mit arp-scan (managementfähige Switches) beginnen, weil am einfachsten. Problem dabei, welches Netz, wenn irgendwelche Leute das lokal managen. Dann STP. Dann den Rest der "Bande".

Mit Firewall, Proxy, ,Domaincontroller/ActiveDirectory/GPUs, Accesslisten auf Routern und MAC-Filtern auf bekannten Switches kann man auch recht zentral und vom Admin-PC aus disziplinieren.

(Lolek und Bolek habe ich gemocht! )