Fritz!Box Anschlussschema für LLDP optimieren

[schnurzegal]

Nur so als Hinweis: LLDP geht mit der 7.90-115685 BETA (Pre 8) OS und HP Aruba Switch auch nicht (richtig). Komischerweise werden kleine Netgear Switche (GS308x) ohne den HP schon korrekt angezeigt. Also. So richtig klappt das generell nicht, wenn Thermostate und Fensterschalter an LAN statt am SHG verortet werden ...

 

[Ldwg2002]

LLDP, LLDP-MED ein IEEE Standard 802.1AB "in April 2006" wird für AVM erst jetzt mit MESH als Marketing im Verkauf interessant.

LLDP ... Das wird diesjahr bestimmt noch besser. ... nicht so hinterher, weil eine heimische Topologie ... gut überschaubar. ... Eine beruhigende Bestätigung, daß die Teilnehmer mit erwarteten Geschwindigkeiten angebunden sind - oder ein Repeater per LAN und nicht per Funk angedockt ist - reicht mir da völlig.

Das ist auch meine Sichtweise - "nice-to-have" - mehr nicht. (provokant: Scheiße fürs Auge.) Ob AVMs einmalig guter Support #1 so funktioniert? Inzwischen ist die AVM-Produktlandschaft ein Zoo. Ein Zoo der Galapagosinseln, ein eigenes Ökosystem das Standards eigens umsetzt?

Es ist enttäuschend.

Deshalb berichte ich hier über meine (wie immer schmerzlichen) Erfahrungen. Beim anstehenden Umbau zu Glasfaser (Signatur: siehe V) will ich nicht auf Schönheit verzichten und wir haben diesjahr 2025.

Diese wichtigen Grundlagen zur Topologie ( zuviele Switches) behalte ich in Erinnerung, (sind in V erfüllt).

macht es am meisten Sinn so wenig wie es geht über LAN direkt an eine Fritzbox zu hängen
Die Veränderung brachte eigentlich nicht der Wegfall des Switches, sondern nur die eine Leitung zu der Fritte.

dass die Fritzbox kein wirklicher Switch ist und dafür auch noch einen recht schwachbrüstigen Prozessor hat.

AVM sagt zur 7490 im Wissensdokument #3384 das gleiche wie zur zukünftigen 4050

Die FRITZ!Box kann Switche, die keine LLDP-Informationen weiterleiten ("Unmanaged Switch"), nicht erkennen.

Nach meinen Erfahrungen der letzten 24h widerspreche ich dieser Aussage vehement. Der Satz verleitet zum falschen Schluss, dass ein "managed switch" besser geeignet wäre. Manchmal fangen "managed" die Probleme erst so richtig an, denn es kommt ein ganzer Strauß aus IEEE 802.1 ins Spiel und mit 802.1Q / VLANS schießt man sich wahrscheinlich ins Aus, weil es dann am Switch ein Standard VLAN1 gibt (native VLAN).

Zusammenfassung: Zwei "smarte" Boxen werden doch einen dummen Switch dazwischen entdecken.
In FritzOS selbst steckt die Fähigkeit zu LLDP / .1AB, offiziell als Feature ab FritzOS>07.5x (am Router). Der Link AVM #3384 Fehlerhafte Mesh-Einträge informiert bereits für FritzOS>07 über LLDP (frühere Laborversionen, z.B. LLDP Switche oder hier). Vermutung: An einem Router FritzOS>07.5x darf (muss) der Switch, der erkannt und dargestellt werden soll, dumm bleiben (ohne LLDP / .1AB), wenn weitere AVM-Produkte (mind. 1) mit FritzOS>07 (und Clients die LLDP können, z.B. Linux, Windows LLTD) am Switch verwendet werden. In Verbindung mit älteren FritzOS>06 muss der Switch dumm bleiben und darf keinesfalls 802.1Q / VLANS unterstützen.

Das Vorhaben und die Erfahrungen im ersten Schritt ...
Start: Router 7490_07.60, backhaul von 100 Mbit/s unmanaged Switch (noname: Sempre 24port, 10-100 Mbps)
Ziel: Router 4050 mit ONT-Modem, backhaul von 1 Gbit/s managed (mit LLDP, LLDP-MED aka IEEE 802.1AB)

Der Weg vom Start zum Ziel begann mit dem
1.Schritt, backhaul: 1 Gbit/s managed Switch / LLDP 802.1AB; (ersetzt stupid noname)

• Router7490 und an LAN1 der managed HP Aruba Switch 1930, JL680A,
  daran alle AccessPoints (7272_06.89) mit allen Geräten im LAN und WLAN.
  .
• HPE Aruba Instant On 1930 8G 2SFP Switch (JL680A) Link page 13, Link
  kann beides IEEE 802.1Q und .1AB aka LLDP u.a.m.
  Spoiler: IEEE 802, siehe Seite 13

  IEEE 802.3 10BASE-T
  IEEE 802.3u I100BASE-TX
  IEEE 802.3ab 1000BASE-T
  IEEE 802.3z 1000BASE-X
  IEEE 802.2af PoE (PoE models only)
  IEEE 802.3at PoE (PoE models only)
  IEEE 802.3x Flow control
  IEEE 802.1Q VLANS
  IEEE 802.1p Priority
  IEEE 802.3ad Link Aggregation Control Protocol (LACP)
  IEEE 802.1X Port Access Authentication
  IEEE 802.3az Energy Efficient Ethernet
  IEEE 802.1D Spanning Tree Protocol
  IEEE 802.1W Rapid Spanning Tree Protocol
  IEEE 802.1S Multiple Spanning Tree Protocol
  IEEE 802.1AB Link Layer Discovery Protocol
  • Aruba1930: die GUI zeigt unter "Neighbor Discovery > LLDP" Boxen mit FritzOS >07.x korrekt an, z.B. die zwei kaskadierten Router7430_07.31 werden mit LLDP als "Bridge, WLAN AP, Router" erkannt, die "alten" APs 7272_06.89 bleiben unerkannt.
    .
• Probleme bei den Clients (hosts) gab es jetzt überall
  • Nutzer beklagen Performance allg. und WLAN-Probleme (Vorschaltseite, Ticket)
    Hintergrund: Es ist ein IAM-Konzept (Unbeschränkt vs. Standard=Nichts) konfiguriert und nutzt Internet > Filter > Zugangsprofile und Kindersicherung am Router.
    Jeder bekannten MAC-Adresse wird eine feste IP-Adresse (außerhalb des DHCP-Intervalls) zugewiesen und erhält das unbeschränkte Zugangsprofil. Jede unbekannte MAC bekommt irgendeine IP (aus dem DHCP-Intervall) aber keinen Zugriff nach Außen (Standardprofil).
    Hinweis: Link AVM #214 zu Kindersicherung (und Zugangsprofile)
    "Ab FRITZ!OS 6 leiten FRITZ!Boxen, FRITZ!Repeater und FRITZ!Powerline Informationen über mit ihnen verbundene Geräte an die FRITZ!Box weiter, die den Internetzugang herstellt. Dadurch kann die Kindersicherung auch an Geräten genutzt werden, die über ein zusätzliches FRITZ!-Produkt mit der FRITZ!Box verbunden sind." (Der Switch dazwischen ist immer unsichtbar.)
    
    Meine Vermutungen zur Ursache ...
  • A) WLAN mit PSK am Accesspoint mit FritzOS-06.89,
    Der Router>07.5x (für LLDP erforderlich) erkennt Paketmanipulation (die VLAN-ID) und vermutet Missbrauch bzw./und ordnet die identifizierte MAC (mit VLAN-ID im Paket) als unbekannt (nicht in das Zugangsprofil unbeschränkt) in das Standardprofil ein (ohne Außenzugriff). Im Standardprofil (ohne Zugriff) wird die Kindersicherung aktiviert bzw. ein Ticket wird verlangt.
  • B) Unterschiedliche FritzOS-Generation, dazwischen ein "smart Switch" mit 802.Q1.
    Der Accesspoint-06 kommt mit der VLAN-ID nicht klar. Der Router-07.60 kommt mit VLAN1/"untagged" Paketen klar. Was machen FritzOS>07. und FritzOS>06.(89) bei einer vorhandenen VLAN-ID unterschiedlich? https://ausbildung-in-der-it.de/lexikon/vlan-tag
    .
• Maßnahmen:
  • Im LAN bzw. Router7490 IPv6 ausgeschaltet, ist irrelevant in diesem Zusammenhang.
  • Tausch 1 Gbit/s unmanaged Switch D-Link DGS-1024D Link, kann aus 802.1.. nur QoS.1p
    Spoiler: kein .1AB, kein .1Q, nur QoS.1p

    IEEE 802.3 10BASE-T
    IEEE 802.3u 100BASE-TX
    IEEE 802.3ab 1000BASE-T
    IEEE 802.1p Quality of Service (QoS)
    IEEE 802.3x Flow Control supported for full-duplex, Auto-negotiation
    IEEE 802.3az Energy-Efficient Ethernet (EEE)

Ergebnis, backhaul: 1 Gbit/s, unmanaged Switch (kein LLDP.1AB, kein VLAN.1Q),
alles (inkl. IAM über die Filter: Zugangsprofile und Kindersicherung) läuft wie zuvor.

Mein Fazit: Mit renommierter Profi-Hardware, wie hier alle naselang empfohlen, hätte ich keine Probleme erwartet, nicht mit Consumerprodukten gemischt.

Warum erkennt die Fritz!Box die Switche und die Netzwerktopologie nicht korrekt?
Konzentrieren wir uns auf die eigentliche Frage: Wie richtet man die LLDP-Funktionalität richtig ein?

Meine Erwartung an einen Standard: Es muss nichts richtig eingerichtet werde, keine Tricks #743-745 (@St.Boom, @martale) oder irgendein magischer Zauberspruch "mit einer Discovery-Funktion (keine Ahnung ob es LLDP ist)".

AVM sagt in #3384 eindeutig: smarter Switch mit LLDP. Das ist m.E. falsch. Im Consumer-Netzwerk gilt: Der Switch muss LLDP nicht aktiv können, es geht um die Durchleitung der Informationen. Pakete weiterleiten kann jeder Switch. LLDP ist ein Standard, kein Marketingzauber. Versucht AVM alleine zu hexen? Es hat den Anschein, dass die Infos die andere LLDP.1AB-Sprecher (z.B. der smart switch Aruba 1930) im Netzwerk ermitteln (noch) nicht als Erkenntnis im FB-Router mit einbezogen werden.

AVM muss neben IEEE 802.1AB auch die Paketmanipulationen für das native VLAN-ID durch IEEE 802.1Q in FritzOS berücksichtigen, insb. für die Filter: Zugangsprofile und Kindersicherung (vermutlich ist das ab >07 erfüllt). Dann zahlt es wieder auf die Marke und "AVMs einmalig guter Support" ein.

Ich habe im Mesh zwischen meiner 5690 Pro und einem DVB-C zwei Switches, ein TP-Link "TL-SG1210MPE" und *dahinter* ein Tenda "TEG1105PD". Der TP-Link gibt sich nicht als Switch zu erkennen, der "dumme" Tenda hat die dauerhafte Anzeige eines Switches ausgelöst,

@H´Sishi ich darf anehmen, dass du kein subnetting auf Layer 2,5 einsetzt. Sofern möglich, kannst du bitte deine beiden Switches (vermutlich mit Werkseinstellung) bzgl. VLAN-ID vergleichen? Wird auch VLAN1 als Standard verwendet?

• _ko_ TL-SG1210MPE, der kann .1Q aka VLAN / IEEE 802.1Q
  IEEE 802.3i, IEEE 802.3u, IEEE 802.3ab, IEEE 802.3af, IEEE 802.3x, IEEE 802.1q, IEEE 802.1p, IEEE 802.3at, IEEE 802.3z
  
  
• _OK_ Tenda TEG1105PD , der kann weder .1AB / LLDP noch .1Q / VLAN
  IEEE 802.3, IEEE 802.3u, IEEE 802.3x, IEEE 802.3ab, IEEE 802.3af, IEEE 802.3at

Ich weiß halt nicht, ob bei meinen Netzwerkswitchen von Netgear das VLAN ein Problem darstellt.
Es muss ein VLAN gesetzt werden (habe ich ab Werk übernommen "VLAN1"), jedoch ist dieses auf allen Ports "untagged".

Mir war auch im GUI des Aruba1930 die überall einheitliche VLAN-ID aufgefallen,
gleiches Szenario: Werkseinstellungen, gleiches Verhalten: VLAN1 / Ports "untagged".

@Rainbird-1 Dein Hinweis lies mich aufhorchen und ich möchte deine Beobachtung bestätigen und für meine Probleme als Ursache erkennen. Leider hatte ich von der Aruba-GUI keine Screeshots angefertigt. An AVM ist die Beobachtung (und Vermutung) berichtet. Es bleibt enttäuschend, weil bei AVM außerhalb von AVM mit IEEE-Standards nichts vorhersehbar ist. Die Mesh-Darstellung klappt besser, wenn Fremde da'switch'en, die auch LLDP.1AB können, kein VLAN.1Q sprechen. Sonst wäre die Mesh-Darstellung bei H´Sishi mit aktuellem FritzOS schon korrekt.

Ausblick:
Siehe JPG im Anhang, heute morgen auf den "dummen Switch" umgesteckt. Unglaublich oder wunderbar? Meine Nachbarn wollen mit dem IAM-Konzept im Haus nur zuverlässig in "ihr Internet" und keine Experimente. Deshalb wird es kein JPG mit managed Switch geben, weil .1Q (.1AB eher nicht) zwischen Router und Client das IAM-Konzept stören, Internet > Filter: Zugangsprofile und Kindersicherung (ab FritzOS>06). Können alle Accesspoints FritzOS>07, sollten in der Grafik die Clients zugeordnet werden können und nicht mehr gesammelt aufgelistet. Vielleicht funktioniert dann auch das "IAM-Konzept mit Zugangsprofil und Kindersicherung" über einen "managed switch". Evtl. teste ich mit der 4050 nochmal den managed Switch. Wozu? Zu viel KI macht das Netzwerkenleben schwer.

@ Aruba 1930: Ein managed Switch mit GUI ist nice-to-have, man sieht dass die MAC's an dem Port auftauchen wo sie sein sollen, mit einem WLAN-Mesh interessant, aber in ständiger Veränderung,

AVM-Standards unterschiedlicher Generationen und die IEEE-Standards fremder Komponenten verstehen sich nicht oder kollidieren. Für FritzOS unterschiedlicher Generationen ist 802.1Q / VLAN wahrscheinlich eine "fehlerhafte" Paketmanipulation in Layer 1und2 (Bitübertragung und Sicherung), die das Sicherheitskonzept einer FritzBox alarmiert.
conclusio: Use Consumerproducts from Galapagos only, dont mess up with the rest of the world.

EDIT 5 Tage später JPG2: "Heimnetz > Mesh > Mesh-Übersicht" zeigt inzwischen keinen Switch mehr an. Woran das liegt? Wen interessiert es? Der DAU mit KI will in "sein Internet". Strom kommt aus der Steckdose. Internet aus dem WLAN.