6
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?
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.
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?
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.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31628092062
Url: https://administrator.de/forum/netgear-gs752tpv2-reboot-lldp-snom-31628092062.html
Ausgedruckt am: 22.12.2024 um 06:12 Uhr
6 Kommentare
Neuester Kommentar
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:
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) 
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.
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.
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
, 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?
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
, 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?
1
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.
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.
Zitat von @clSchak:
LLDP verursacht eigentlich keine Last, wenn ein Switch damit Probleme haben sollte, austauschen.
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%
Bis auf die Updates nichts verändert... alle Switche halt einmal Kaltgestartet... keine Abstürze mehr 
