Bei den typisch managebaren Switches gibt es eine STP/RSTP Funktion sowie Filterung von BPDU-Paketen. Die Modi können sowohl aktiv als auch passiv erfolgen.
Zumindest haben die meisten Switches LLDP als pro Port Option noch in den Settings. Gibt es hier Probleme, sollte man bei intelligenten Switches unbedingt darauf achten, das BPDU-passiv Mode pro Port aktiv bleibt und das der Dienst LLDP auch dort aktiv und transparent ist. Unmanaged Switches, also die typischen 8-Port 10 Euro Switches, unmanaged, versagen hier oftmals.
Nicht zu verwechseln mit CDP (Cisco Discovery Protokoll).
Man muss auch beachten, das mit den neuen Versionen zur "Loop-Detection, einstellbar über das AVM-Support-Menu softwäremässig bei der LAN-bridge dann das STP-Protokoll linux-seitig zur Loop-Erkennung mit genutzt wird. Nachgeschalte Switches kann man hier dann auf "STP-aware" setzen, wenn sie nicht aktiv an der
Master-Bridge "Auslosung" teilnehmen sollen. Da kann es dann schnell passieren der der neue STP/RSTP-Master, abhängig vom "Weight" dieser STP-Bridge
zum Master für das ganze Netz wird - in diesem Fall müsste die Fritzbox in den Slave-Betrieb gehen. Per Default haben switch-STP ein Gewicht von 32768, ist
dieser Wert an einer Fritzbox geringer, so wird sie, wenn sie korrekt arbeitet, dann zu einem Slave im dümmsten Fall - womit sie die Kontrolle über weitere
"nicht-STP/LLDP-aware" Geräte verlieren kann. Anders kann es sich dann verhalten, wenn alle Geräte dann nur noch an dem nachgeschalteten Switch hängen.
Dieser handhabt die angeschlossenen Geräte dann PRO Port als EDGE-Ports (STP/LLDP Off) - oder als Aktiv (wenn man weitere Switches in die Kette pakt, oder
die Ausgabeports stehen auf STP-aware. Normale Geräte (also EDGE-Ports), wie PCs, die kein STP-Protokoll haben, und auch kein LLDP per Default nicht unterstützen, ensollten zwingend immer als EDGE-Port "passiv" geschaltet werden. Einzig der Uplink-Port muss alle Protokolle und Optionen aktiv haben die auch der Upstream-Router "erwartet" ;-)
"Kommen da propitäre" Sachen noch hinzu muss man sich ggfs ansehen, wie das L2 konfiguriert ist. Viele Switches schaun sich den Traffic untagged/tagged an und auch die Klassifizierung der Datenflüsse. Hier gibt es dann noch "EDGE-Filterung", wo vielfach VLANs umgemappt werden, BPDU-Pakete entfernt werden (bei EDGE-Port Mode immer das Fall!) - und es werden Nur reine Ethernet-Frames durchgelassen, also IP-Class Traffic durchlassen, die ipv4 und ipv6 + vlan tag durchlassen.
ARP-Filterung nach Rules sind weitere Fallstricke - so kommen nicht mehr alle Anfragen zu allen Ports immer durch.
Auch gibt es Filter für Multicast, und MAC-Filterung oftmals als Settings. Hier kann man auch gut Fehler einbauen, wenn man zu restriktiv filtert. Viele Switches
filtern dann auch "Broadcast-Muell" und auch MultiCast traffic, wie MLD, igmp v2 igmp v3 nochmal extra und haben dann Broadcast-Storm-Security.
Repater, die z.b. auf Broadcast-Pakete angewiesen sind, werden ueber Multicast-Adressen von der Fritzbox bedient, sind dann auch geblockt und erreichen nur noch den Switch - kommen aber nicht mehr an den Ausgabeports dran (Stichwort: igmp-relay, proxy & usw.) - Als Ergebnis erscheint dann der Switch als MAC-Adresse,
da einzig nur diese Komponente noch "aware" ist und mit den Paketen am Upstreamport etwas anfangen können. Ab dann beginnt das Filtern zu den Ausgabeports.
Ich habe solche Filter in meinen Switches per Default deaktiviert, ebenso Optionen wie "Broadcast-Storm-Control". Und ich achte darauf, das alle Ports
EDGE-Ports sind.
Testweise kann man versuchen, AVM-Repeater auch mit "stp-aware" mit DEAKTIVEM BPDU-Filter dann man zu confen. In diesem Modus reagieren jedoch alle
Switches beim anstecken von Devices pro Port mit massiven Verzögerungen bis zu 5-10 Sekunden, bis die "valid" erreichbar sind. Der Grund ist, das bei Aktivierung eines einzelnen Ports zuerst einmal eine Loop-Detection durchgeführt wird, STP aktiualisiert wird, LLDP-Datenbänke refreshed werden und erst am Ende
der Port auch wirklich aktiv wird. Sieht man auch im Logfile:
Anstecken: Port wird immer sofort erst mal blocked, dann Capatibilty-Check, und einige Sekunden später: Port dann aktiv.
Solange man jedoch nur Rechner und Laptops anschliesst, den Port für diese Geräte IMMER auf EDGE-Port setzen - ganz einfach weil in der Regel diese
Devices niemals STP, LLDP & co. per default sprechen können. Würde auch kein Sinn machen, Einen Windows Rechner mit nur einem Ethernet Port und keinem Redunanz-Port via STP aktiv zu halten. Ausser man baut sich ein Failover mit 2 Links und gleicher Bridge/Ip-Adresse - da muss dann am Zielgerät auch eine STP-Fähigkeit vorliegen, mindestens jedoch eine "STP-passiv-Aware". LLDP hingegen, also Informationen preisgeben, können auch nur die wenigstens EDGE-Geräte - im Grunde nur weitere Switches anderer Hersteller und Router das der direkte Switch-Partner weiss, was die capapilititys der Nachbarswitches sind.
Beispiel: Cisco oder Juniper als Router -> nachgelagerte Switches -> weitere Switches, die ggfs in einem Trunk verbunden sind. So eine Gruppe sollte dann
auch LLDP überall aktiv haben.
Die Dokumentation von den Switches selber und die Auswirkungen sind da in .pdf Datei meistens sehr gut beschrieben, welche Optionen auf was welche
Auswirkungen haben. Netgear Switches reagieren z.b. völlig anders als TP-Link Switches, es sind oft nur Kleinigkeiten bei den Ausgabe-Ports was die FIlterund angeht, neben globalen Filterfunktionen und Features die das ganze Gerät betreffen können. Als Beispiel sind hier eben Broadcast-Storm-Detection und globales STP OFF; als auch LLDP-Filter vollständig abgeschaltet.
Hier kann man gut ansetzen, wenn dort angeschlossene Reapeater auf einmal nicht mehr "vorhanden sind.
-- Zusammenführung Doppelpost gemäß Boardregeln https://www.ip-phone-forum.de/threads/ip-phone-forum-regeln.297224/ by stoney
Ich habe noch eine potentielle Fehler-Quelle bei nachgeschalteten intelligenten Switches:
Es geht um das sogenannte "Default-VLAN 1":
Grundsätzlich dient das "Default-VLAN 1" als "untagged" und ist der Werksmodus. Sämtliche Protokolle, wie STP/LLDP & co laufen normalerweise immer untagged
zwischen verschiedenen Geräten dann auch darüber.
In der Regel verwendet man auf solchen Switches dann weitere VLANs - allerdings übertragen andere VLANS dann nur als eigeneständige Gruppen IP-Informationen.
Da die Fritzboxen selber angeblich ja nur "untagged" sind ergibt sich aber bei vielen Switches ein Kompatibilitäsproblem was man an verschienen Clients nachvollziehen kann:
Bei vielen Switches gibt es unterschiedliche Behandlungsfunktion was mit "Tagged" Frames auf einem als untagged konfiguriertem Port passieren soll:
Variante 1: DROP wenn tagged Frames kommen, 2: Abwurf auf ein "Default-VLAN (die PVID), oder 3: mappen in ein anderes VLAN, 4.: Abschneiden des Tags.
Bei der Fritzbox ist es entscheidend, wenn man z.b. ein VLAN 10 anlegt, die Fritzbox in diesem VLAN einträgt, der Eingangsport zur Fritzbox dann als untagged korrekt geconfed ist, dann würde der ganze Traffic der UNTAGGED auch erwartet wird, innerhalb des Switches dann auf VLAN 10 behandelt und an den Ausgabeports entweder as tagged VLAN10 oder untagged ankommen. Soweit zur Theorie.
In der Praxis ist es aber ERFORDERLICH das man bei einer derartigen config unbedingt die PVID an diesem Port auf DASSELBE interne vlan setzen muss.
(VLAN 10 -> PVID 10)
VLAN 1 ist "normal" untagged - leider meinen einige Geräte dann aber trotzdem die Pakete mit einem "leeren" Tag zu übertragen, Der Switch bekommt
dann solche Pakete "nicht so ganz" untagged, sondern als Tagged mit VLAN-Tag 1 - womit dann LLDP & co wieder nicht funktoniert, weil tatsächlich dieser
Traffic immer untagged erwartet wird. Ich habe bei einigen Daemon-Diensten der Fritzbox schon Pakete geloggt, die kamen zwar "untagged", hatten
aber trotzdem einen fehlerhaften tagged Header - und dort stand dann gar keine VLAN-ID drin, bzw. war das Tag-Info-Field im Header fehlerhaft oder leer.
Die PVID-Funktion hat die Aufgabe, Traffic von anderen VLANs / falschen Paketen, die den TAG abschneiden usw. dann als untagged mit in das für diesen Port vorgesehene "Default/Abwurf-VLAN" korrekt mit einzutüten.
Am Beispiel VLAN10 würde man dann den Eingangsport zur Fritte als UNTAGGED confen und im Bereich der PVID-Settings den PVID auf 10 setzen.
- dann wird der gesammte Traffic inkl. eventueller "fehlerhafter" Pakete ebenso ins VLAN 10 mit ausgegeben und wird so NICHT gefiltert durch die Switch-Engine.
Da man allerdings dann nicht mehr das Default VLAN 1 des Switches selber verwendet, können LLDP und STP & co komplett auf der Strecke bleiben, da
eben genau sowas nur ueber das Management-VLAN untagged 1 vorgesehen ist. Es kann also gehen, muss es aber nicht.
Setzt man das PVID nicht, belässt es also auf dem Default von PVID 1 - hängt es dann bei den Ausgabeports oftmals davon ab, wie das angeschlossene Endgerät
mit dem was der Switch ausgibt noch klar kommt: PCs geht meistens alles noch, ein weiterer Switch oder Router ist zb. nicht mehr Pingbar und MultiCast kann komplett auf der Strecke bleiben.
Was das korrekte Handling von "VLAN 1" als immer untagged angeht - verhalten sich leider viele Hersteller recht unterschiedlich.
Ist leider etwas komplizierter und einen Universaltip kann man da nicht geben. Lediglich auf Grundsätzliches hinweisen, wo man gute 20 Kombimöglichkeiten
an nachgeschalteten Switches hätte, je nach Funktionsumfang und vorhandenen Filtern und "falschen Defaults" dort.
In der einfachsten Form vergibt man dem Switch zum Management eine IP aus der Fritten-Range, und nutzt nur das VLAN 1 - aber man muss eben darauf achten,
das der Eingangsport eine korrekte PVID Zuordnung hat und eben sachen wie MLD-Proxys und Broadcast-storm-Filter erst mal deaktiviert bleiben im Switch.
Lösungen zum Debug:
a.) auf der fritte unter freetz mit tcpdump oder ngtraf im promiscous mode schnueffeln. vorher im Support-Menu unbedingt die L2+Accelerator Optionen vorübergehend deaktvieren
b.) Jeder managebare Switch hat eine Funktion die sich "Mirrorport" nennt. Hier wird dann eine 1zu1 Kopie in Senderichtung aller ein und ausgehenden Pakete
von einem beliebigen Port ausgegeben den man monitoren möchte. An dem Kontrollrechner kann man dann wieder mit wireshark, tcpdump & co sich ansehen was tatächlich ankommt & abgeht.
Hier kann man dann z.b. das Mirroring mal auf den von der Fritte kommenden Eingangsport legen und zum Vergleich dann auf einen typischen Ausgabeport,
wo ein Repeater dran hängt. Da merkt man dann recht schnell ob das komplette MultiCast was in den Switch rein geht auch an den Ausgabeports vollständig
wieder rauskommt - oder eben so Scherze passieren, das der "igmp-proxy" sich selbst mit seiner MAC in die Mitte setzt und ggfs Pakete on the fly "umschreibt" ;-)
