themuck
Goto Top

Netgear gs752tpv2 reboot, LLDP Snom?

Moin,
am 12./13. August haben wir bei uns die Telefonanlage umgezogen. Wir haben eine Hardware variante bekommen, für die Box habe ich an unseren "Hauptswitch" am Port den Vlan Tag gesetzt.

Dazu habe ich bei unseren beiden SNOM M700 folgendes noch aktiviert: Discovery, LLDP-MED Send: Aktiviert. Und LLDP-MED Send delay: 30. Und die Geräte Setzen jetzt selber den VLan Tag. Die anderen Yealink Telefone wurden resettet und neu Provisioniert... sind aber in den Grundeinstlungen eigentlich identisch geblieben.

Beide Snom Basisstationen hängen nicht direkt an dem gs752tpv2 Hauptswitch, sondern jeweils an einem GS728TPv2. Die Verbindung ist leider gs752tpv2 -> GS728TPV2 -> GS728TPV2 (Gebäudeteil zu Gebäudeteil). Firmware war nicht aktuell.

Das ganze Setup lief vor der kleinen Umstellung -> 1 year 247 days 4 hours 3 minutes 55 seconds :D.

Danach gab es jetzt zweimal einen Neustart des Switches, es läuft bis auf den reboot alles wie gewohnt. Bei den GS728TPV2 keine reboots... Was anders ist, am Hauptswitch hängt eine OPNsense als DHCP-Relay für die VLans.

Gestern Abend habe ich dann alle Switche auf den Aktuellen FW stand gebracht, lief auch Problemlos. Schaue ich mir jetzt in LibreNMS zum Beispiel den Port der Hardware PBX an, so gibt es da ein erhöhten "Grund Traffic" seit dem FW-Update, wieso?
graph

Konfiguriert sind nur VLans und für die Voip Telefone VLan Tag mit DSCP. Das war aber schon die ganze Zeit so.

Es kann natürlich Zufall sein aber bei der Suche im Netz findet man zumindest ein paar Treffer in Zusammenhang mit LLDP und reboot / crashed switchen. Ich kann es mir sonst nicht erklären. Außer das eventuell das Netzteil? zufällig einen weg hat. Ich hab LLDP bei den SNOMs wieder deaktiviert und werde es beobachten. Mit dem Logging bei den Switchen muss ich mich noch weiter beschäftigen. Aber es kann je nicht sein das sowas zum reboot führt.

Content-Key: 31628092062

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

Printed on: June 13, 2024 at 00:06 o'clock

Member: aqui
aqui Aug 24, 2023 updated at 14:04:40 (UTC)
Goto Top
so gibt es da ein erhöhten "Grund Traffic" seit dem FW-Update, wieso?
Mirrorport auf den PBX Port einrichten und mit einem Wireshark nachsehen WAS dieses ominöse "Grundrauschen! ist! Das weisst du wasserdicht was es ist statt zu Kristallkugeln.
Konfiguriert sind nur VLans und für die Voip Telefone VLan Tag mit DSCP.
Wenn du taggest dann nutzt du (bzw. die Anlage gibt das vor) immer eine Layer 2 Priorisierung für die Voice Daten mit 802.1p!
802.1p ist immer Bestandteil des 802.1q Headers so das Layer 2 priorisierter Traffic zwangsweise immer einen VLAN Tag haben muss.
DSCP macht das QoS im Layer 3 (IP Header) und erzwingt damit kein Tagging der Voice Daten. Ist also etwas einfacher umzusetzen erfordert aber zwingend Switchhardware die diese Information auch lesen kann. (DHCP Trusting bei Layer 2 Switches). Z.B. hier bei einem Cisco SG/CBS Switch:
dscp
Ein durchgängiges QoS Verfahren erleichtert das QoS Management! Siehe auch hier zu der Thematik.
im Netz findet man zumindest ein paar Treffer in Zusammenhang mit LLDP und reboot / crashed switchen.
Du meinst in Bezug auf Netgear Gurken, oder? Für andere Hersteller gilt der Unsinn natürlich nicht.
So sähe es z.B. bei Ruckus Switches aus:
lldp med network-policy application voice tagged vlan 40 priority 5 dscp 46 ports ethe 1/1/2
lldp med network-policy application voice-signaling tagged vlan 40 priority 3 dscp 26 ports ethe 1/1/2
 

icx7150-switch#sh lldp neighbors detail ports ethernet 1/1/2
Local port: 1/1/2
  Neighbor: 0024.e86e.d567, TTL 96 seconds 
    + Chassis ID (network address): 172.16.40.120 
    + Port ID (MAC address): 0024.e86e.d567 
    + Time to live: 120 seconds 
    + System capabilities : bridge, telephone 
      Enabled capabilities: telephone 
    + 802.3 MAC/PHY          : auto-negotiation enabled 
      Advertised capabilities: 10BaseT-HD, 10BaseT-FD, 100BaseTX-HD, 
                               100BaseTX-FD, 1000BaseT-FD 
      Operational MAU type   : 1000BaseT-FD 
    + MED capabilities: capabilities, networkPolicy, extendedPD 
      MED device type : Endpoint Class III 
    + MED Network Policy 
      Application Type  : Voice 
      Policy Flags      : Known Policy, Tagged 
      VLAN ID           : 40 
      L2 Priority       : 5 
      DSCP Value        : 46 
    + MED Network Policy 
      Application Type  : Voice Signaling 
      Policy Flags      : Known Policy, Tagged 
      VLAN ID           : 40 
      L2 Priority       : 3 
      DSCP Value        : 26 
    + MED Extended Power via MDI 
      Power Type     : PD device 
      Power Source   : Unknown Power Source 
      Power Priority : Critical (1) 
      Power Value    : 4.2 watts (PSE equivalent: 4400 mWatts) 
Works as designed und erwartungsgemäß natürlich auch stabil ohne Abstürze oder Reboots!! ­čśë
Member: themuck
themuck Aug 24, 2023 at 15:11:45 (UTC)
Goto Top
Moin erstmal danke, ich schau mir das alles noch mal in ruhe an zum Thema QoS. Was mich wunderte ist halt das dieses Grundrauschen nach dem Update der Switche erfolgte :D, und das betrifft nicht nur diesen Port. Sonst habe ich da am Netz nichts verändert.

Was ich auf die schnelle zu LLPD + crasch gefunden habe.

https://atcomsystems.ca/forum/ubbthreads.php/topics/554735/bricked-short ...
https://quickview.cloudapps.cisco.com/quickview/bug/CSCvi71623
https://community.spiceworks.com/topic/1102666-netgear-gs752ts-crashes

Da das Voip Setup bis dato auch ohne murren lief, und die Veränderungen sich ja IMHO in grenzen hielten wundert es mich halt das der Eimer jetzt einen Reboot macht. Vor allem, warum machen es die anderen Netgear Smart Switche nicht. Aber eventuell liegt es ja auch an den Settings an der Hardware PBX... aber IMHO darf es ja nicht zu einem Reboot kommen.
Member: clSchak
clSchak Aug 24, 2023 at 16:34:23 (UTC)
Goto Top
LLDP verursacht eigentlich keine Last, wenn ein Switch damit Probleme haben sollte, austauschen.

Bzgl. Reboot: davor ist Ruckus auch nicht befreit, die 8.0.90d Firmware der ICX Switche hatte das Problem auch, gelegentlicher "warm reboot" aus ansonsten unerklärlichen Gründen.

Gab es einen Grund warum du die Switche gepatched hast? Ist eigentlich eher selten oder man hat Geräte wie Cisco im Einsatz die immer wieder mit Sicherheit"Features" aufwarten face-smile, keine Ahnung wie Netgear da abschneidet. Wüsste jetzt von keiner FW-Version der ICX die ein Sicherheitsproblem hat.

Und bzgl. Problem nach Reboot: evtl. vorher das speichern der Config vergessen? Das der Stand nicht mehr dem des Vorbetriebes gleicht?
Member: themuck
themuck Aug 24, 2023, updated at Aug 25, 2023 at 04:34:59 (UTC)
Goto Top
Der Grund des Patches war das der Switch 1 year 247 days 4 hours 3 minutes 55 seconds ohne murren lief und nach der PBX "Umstellung" eben 2x in zwei Wochen nen reboot hingelegt hat.

Die Änderung wie beschrieben, an einem Port Vlan Tag gesetzt, bei den Snom M700 die an anderen Switchen hängen auch da VLan Tags und an dem Snoms LLDP Aktiviert. Dazu in den Netzwerkeinstellungen bei Snom und der PBX das VLan gesetzt.

Das Setup lief mit der Hardware schon lange, nur ohne die Änderungen und der VLan Zuordnung bei Endgeräten.

Der reboot geschah auch nicht sofort, das geschah das erste mal 5 Tage nach den Änderungen ;). Schauen wir mal ich kann das ja nach und nach wieder in den Uhrzustand bringen :D.

https://community.spiceworks.com/topic/2459029-network-switches-seem-lik ...

Aber es kann ja nicht sein das der Switch dann gleich nen Reboot macht. In der Vergangenheit vor 3 Jahren, ist der Switch öfter mal "Eingefroren", hat dann seine Smarten Funktionen verloren. Web Interface nicht erreichbar, das wurde aber durch ein FW Update behoben.

Ein neuer GS728TPv2 hatte damals (2020) auch ein Problem, der ist ständig abgestürzt in der Grundkonfiguration, da half nur Kaltstart, wurde dann von Netgear getauscht.
Member: themuck
themuck Aug 25, 2023 at 11:12:47 (UTC)
Goto Top
Zitat von @clSchak:

LLDP verursacht eigentlich keine Last, wenn ein Switch damit Probleme haben sollte, austauschen.

also an der last sollte es nicht liegen, die Switche Dümpeln so vor sich hin :D.

PID         Name                       5 Secs    60 Secs   300 Secs
----------- -------------------------- --------  --------  --------
          3              [ksoftirqd/0]    0.00%     0.08%     0.05% 

        731                  miniupnpd    0.33%     0.59%     0.65% 

         58                     [spi0]    0.00%     0.00%     0.01% 

         75          [max3421_spi_thr]    0.00%     0.01%     0.02% 

        602             DiscoveryAgent    0.08%     0.07%     0.08% 

        415                     usaged    7.85%     8.22%     8.15% 

        428                      snmpd    0.00%     1.98%     0.81% 

        445                      polld    0.16%     0.12%     0.10% 

        458                   lighttpd    0.08%     0.00%     0.02% 

----------- -------------------------- --------  --------  --------
Total CPU Utilization                     8.52%    11.13%     9.93% 
Member: themuck
themuck Sep 13, 2023 at 06:40:28 (UTC)
Goto Top
Bis auf die Updates nichts verändert... alle Switche halt einmal Kaltgestartet... keine Abstürze mehr face-sad