22
Cisco SG350X-48P: Reset-Orgie nach Patchkabelanschluss
Hallo zusammen,
ich habe hier einen neuen Cisco-Switch SG350X-48P stehen, der ein merkwürdiges Verhalten zeigt.
Nachdem ich ihn vor zwei Tagen als Austausch für einen HP/Aruba 2530-24G-PoE+ (J9773A) in Betrieb genommen habe, trat das Phänomen auf, dass er nach dem Anschluss diverser Geräte (Switches, IP Phones, PCs, Telefonanlage, WLAN AP) ständig neu gestartet ist. Ich habe dann die Geräte nach und nach noch einmal angeschlossen und irgendwann hörte das ständige Neustarten auf und das Netzwerk lief so, wie ich es erwartet habe.
Heute wollte ich weitere Ports anschließen und das gleiche Spielchen ging bereits beim Anschluss des ersten Patchkabels von vorn los. Als Endgerät war dort ein IP Telefon mit PoE angeschlossen. Da im Gegensatz zum Samstag meine Kollegen heute arbeiten mussten, habe ich erst mal wieder den HP in Betrieb genommen.
Liegt das an einer Einstellung des Cisco-Switches oder ist er defekt?
Es ist unser erster Cisco-Switch, daher muss ich mich hier noch einarbeiten. Im Augenblick habe ich nur ein Voice VLAN eingerichtet und mich beim Tagging an der Konfiguration des HP orientiert.
Ich freue mich auf eure Rückmeldungen.
Danke und viele Grüße
Bodennebel
ich habe hier einen neuen Cisco-Switch SG350X-48P stehen, der ein merkwürdiges Verhalten zeigt.
Nachdem ich ihn vor zwei Tagen als Austausch für einen HP/Aruba 2530-24G-PoE+ (J9773A) in Betrieb genommen habe, trat das Phänomen auf, dass er nach dem Anschluss diverser Geräte (Switches, IP Phones, PCs, Telefonanlage, WLAN AP) ständig neu gestartet ist. Ich habe dann die Geräte nach und nach noch einmal angeschlossen und irgendwann hörte das ständige Neustarten auf und das Netzwerk lief so, wie ich es erwartet habe.
Heute wollte ich weitere Ports anschließen und das gleiche Spielchen ging bereits beim Anschluss des ersten Patchkabels von vorn los. Als Endgerät war dort ein IP Telefon mit PoE angeschlossen. Da im Gegensatz zum Samstag meine Kollegen heute arbeiten mussten, habe ich erst mal wieder den HP in Betrieb genommen.
Liegt das an einer Einstellung des Cisco-Switches oder ist er defekt?
Es ist unser erster Cisco-Switch, daher muss ich mich hier noch einarbeiten. Im Augenblick habe ich nur ein Voice VLAN eingerichtet und mich beim Tagging an der Konfiguration des HP orientiert.
Ich freue mich auf eure Rückmeldungen.
Danke und viele Grüße
Bodennebel
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: 364513
Url: https://administrator.de/contentid/364513
Ausgedruckt am: 25.11.2024 um 03:11 Uhr
22 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @Bodennebel:
Nachdem ich ihn vor zwei Tagen als Austausch für einen HP/Aruba 2530-24G-PoE+ (J9773A) in Betrieb genommen habe,
War der neu und eingeüackt oder schon älter und eingepackt oder schon mal konfiguriert gewesen oder was? Auch ml ein Werksreset gemacht und danach geschaut was der tut?Nachdem ich ihn vor zwei Tagen als Austausch für einen HP/Aruba 2530-24G-PoE+ (J9773A) in Betrieb genommen habe,
Ich habe dann die Geräte nach und nach noch einmal angeschlossen und irgendwann hörte das ständige Neustarten auf und das Netzwerk lief so, wie ich es erwartet habe.
Heisst, du schliesst am Switch Strom an und es geht mit den Neustarten los obwohl kein Patchkabel mit irgendein Gerät dran hing, sondern erst nachdem du X Anzahl Patchkabel mit Y Geräten angepatched hast hörte das Neustarten auf?Heute wollte ich weitere Ports anschließen und das gleiche Spielchen ging bereits beim Anschluss des ersten Patchkabels von vorn los.
Immer am gleichen Port oder ist es egal? Auch ohne das am ende des Patchkabels etwas dranhängt?Als Endgerät war dort ein IP Telefon mit PoE angeschlossen.
Und wenn dort ein Rechner ohne POE dran hängt oder ein weiterer SwitchPort?Liegt das an einer Einstellung des Cisco-Switches oder ist er defekt?
Hört sich nach Defekt an wenn es die Werkseinstellung sein sollte.Im Augenblick habe ich nur ein Voice VLAN eingerichtet
Und ohne Konfiguration tut er es auch?und mich beim Tagging an der Konfiguration des HP orientiert.
Bedenke, dein Cisco ist kein HP. Handbuch zu rate ziehen ist angesagt da HP doch einiges anders meint...Gruß,
Peter
Moin,
ergänzend zu Pjordorfs Anmerkungen/ Fragen, ist auch spannend, ob in den LOGs des Cisco etwas zu lesen ist....
Ich persönlich tippe aktuell mal auf eine Überlast was die PoE Ports betrift, wobei der dann vermutlich die Ports ausschalten/ die Last droßeln würde, nicht aber in einem Endlos-Reboot gerät. Aber wie gesagt: Schaue in die Logs des Ciscos
Und schaue auch mal, dass du eine aktuelle Firmware installiert hast, sofern nicht eh schon vorhanden..
Gruß
em-pie
ergänzend zu Pjordorfs Anmerkungen/ Fragen, ist auch spannend, ob in den LOGs des Cisco etwas zu lesen ist....
Ich persönlich tippe aktuell mal auf eine Überlast was die PoE Ports betrift, wobei der dann vermutlich die Ports ausschalten/ die Last droßeln würde, nicht aber in einem Endlos-Reboot gerät. Aber wie gesagt: Schaue in die Logs des Ciscos
Und schaue auch mal, dass du eine aktuelle Firmware installiert hast, sofern nicht eh schon vorhanden..
Gruß
em-pie
Hallo Peter,
der Switch war aus meiner Sicht neu und originalverpackt. Von daher gehe ich davon aus, dass der in der Werkseinstellung war. Zumindest musste ich beim ersten Einschalten direkt das Standard-Passwort ändern.
Wenn nichts angeschlossen ist, fährt er brav hoch und wartet.
Ob das Problem immer am gleichen Switchport auftritt, muss ich testen. Ich will nicht ausschließen, dass ich am Samstag den betreffenden Port bei der ersten Reset-Orgie mit angeschlossen hatte und danach zufällig den möglicherweise fehlerhaften nicht mehr verwendet habe und der Switch deshalb stabil lief.
Ob PoE eine Rolle spielt werde ich ebenfalls testen.
Die Frage zum Voice VLAN verstehe ich nicht. Ich habe im Cisco von Auto Voice VLAN auf die bei uns eingerichtete VLAN ID gewechselt und das Tagging entsprechend von unserem HP Switch übernommen. Das hat auch alles wunderbar funktioniert. Von daher vermute ich dort keinen Fehler.
Viele Grüße
BN
der Switch war aus meiner Sicht neu und originalverpackt. Von daher gehe ich davon aus, dass der in der Werkseinstellung war. Zumindest musste ich beim ersten Einschalten direkt das Standard-Passwort ändern.
Wenn nichts angeschlossen ist, fährt er brav hoch und wartet.
Ob das Problem immer am gleichen Switchport auftritt, muss ich testen. Ich will nicht ausschließen, dass ich am Samstag den betreffenden Port bei der ersten Reset-Orgie mit angeschlossen hatte und danach zufällig den möglicherweise fehlerhaften nicht mehr verwendet habe und der Switch deshalb stabil lief.
Ob PoE eine Rolle spielt werde ich ebenfalls testen.
Die Frage zum Voice VLAN verstehe ich nicht. Ich habe im Cisco von Auto Voice VLAN auf die bei uns eingerichtete VLAN ID gewechselt und das Tagging entsprechend von unserem HP Switch übernommen. Das hat auch alles wunderbar funktioniert. Von daher vermute ich dort keinen Fehler.
Viele Grüße
BN
Hallo em-pie,
ich glaube nicht an eine Überlast der PoE-Ports, da der HP in der Summe weniger Leistung bereitstellt (195 W, Cisco: 483 W) und stabil läuft. Das hatte ich auch schon im Verdacht und daher am Samstag die 60W PoE-Ports am Cisco abgeschaltet (da hatte ich unsere Server angeklemmt, die ja kein PoE brauchen). Ausserdem haben wir fast nur Class 1 und 2 Geräte als PoE-Geräte, den höchsten Verbrauch haben unsere Konferenztelefone mit ca. 4,5-6 W.
Die Firmwareversion muss ich nachschauen, war aber eine aus 2017.
Viele Grüße
BN
ich glaube nicht an eine Überlast der PoE-Ports, da der HP in der Summe weniger Leistung bereitstellt (195 W, Cisco: 483 W) und stabil läuft. Das hatte ich auch schon im Verdacht und daher am Samstag die 60W PoE-Ports am Cisco abgeschaltet (da hatte ich unsere Server angeklemmt, die ja kein PoE brauchen). Ausserdem haben wir fast nur Class 1 und 2 Geräte als PoE-Geräte, den höchsten Verbrauch haben unsere Konferenztelefone mit ca. 4,5-6 W.
Die Firmwareversion muss ich nachschauen, war aber eine aus 2017.
Viele Grüße
BN
Moin..
sach mal, hast du ein Firmware Update gemacht? wenn du Pech hast, ist das blech von mitte 2016... und die Firmware auch...
allerdings vermute ich das du ein POE problem hast.. 384W sind schnell aufgebraucht.
oder ein Port im P-Panel hat ein schluss gegen masse etc...
Frank
sach mal, hast du ein Firmware Update gemacht? wenn du Pech hast, ist das blech von mitte 2016... und die Firmware auch...
allerdings vermute ich das du ein POE problem hast.. 384W sind schnell aufgebraucht.
oder ein Port im P-Panel hat ein schluss gegen masse etc...
Frank
Wie gesagt, prüfe die Logs auf dem Cisco.
Zur Firmware, die jüngste ist von Sept. 2017 und hört auf die Version 2.3.5.63:
https://software.cisco.com/download/release.html?mdfid=286305760&sof ...
Zur Firmware, die jüngste ist von Sept. 2017 und hört auf die Version 2.3.5.63:
https://software.cisco.com/download/release.html?mdfid=286305760&sof ...
Hallo Vision2015, hallo em-pie,
ich habe noch kein Firmware-Update gemacht. Die aktuell installierte Version ist 2.3.0.130.
Danke für den Link, em-pie.
Wie oben geschrieben, glaube ich nicht an ein PoE-Problem durch zu viele Verbraucher bzw. Überlast, da ja der wesentlich schwächere HP kein Problem mit den angeschlossenen Geräten hat. Aktuell zeigt mir der HP gerade einmal 36 W +/- 6W als Power in Use an:
Ist also noch viel Luft nach oben am Cisco (aktuell: Maximum Available PoE Power(W): 375, Total PoE Power Consumption(W): 4). Derzeit hängt nur ein IP-Telefon dran.
Ich teste die Ports weiter durch, ob er bei einem bestimmten wieder abstürzt.
Danke für euer bisheriges Feedback. Ich melde mich wieder.
VG
BN
ich habe noch kein Firmware-Update gemacht. Die aktuell installierte Version ist 2.3.0.130.
Danke für den Link, em-pie.
Wie oben geschrieben, glaube ich nicht an ein PoE-Problem durch zu viele Verbraucher bzw. Überlast, da ja der wesentlich schwächere HP kein Problem mit den angeschlossenen Geräten hat. Aktuell zeigt mir der HP gerade einmal 36 W +/- 6W als Power in Use an:
Ist also noch viel Luft nach oben am Cisco (aktuell: Maximum Available PoE Power(W): 375, Total PoE Power Consumption(W): 4). Derzeit hängt nur ein IP-Telefon dran.
Ich teste die Ports weiter durch, ob er bei einem bestimmten wieder abstürzt.
Danke für euer bisheriges Feedback. Ich melde mich wieder.
VG
BN
Moin,
Ich würde erstmal die Firmware updaten und dann sehen wir weiter!
Gruß
Kümmel
Ich würde erstmal die Firmware updaten und dann sehen wir weiter!
Gruß
Kümmel
Hallo zusammen,
nachfolgend findet ihr das Flash Memory Log und danach das RAM Memory Log. Im RAM Memory Log habe ich die Voice VLAN ID durch XY ersetzt und die Einträge meiner Anmeldungen an der Weboberfläche des Ciscos gelöscht. Ich hoffe, die Logs sind einigermaßen lesbar.
Wenn ich das richtig interpretiere, scheint es ein Problem mit der Auto-Smartport-Funktion zu sein und hier speziell mit Port 15. Da bei den anderen Einträgen als Datum immer der 10. Mai 2017 auftaucht, bin ich mir nicht sicher, ob das alles Ereignisse von heute sind oder auch schon vom Wochenende.
Ich hoffe, ihr könnt da mehr erkennen als ich.
VG
BN
Hier nun das RAM Memory Log:
nachfolgend findet ihr das Flash Memory Log und danach das RAM Memory Log. Im RAM Memory Log habe ich die Voice VLAN ID durch XY ersetzt und die Einträge meiner Anmeldungen an der Weboberfläche des Ciscos gelöscht. Ich hoffe, die Logs sind einigermaßen lesbar.
Wenn ich das richtig interpretiere, scheint es ein Problem mit der Auto-Smartport-Funktion zu sein und hier speziell mit Port 15. Da bei den anderen Einträgen als Datum immer der 10. Mai 2017 auftaucht, bin ich mir nicht sicher, ob das alles Ereignisse von heute sind oder auch schon vom Wochenende.
Ich hoffe, ihr könnt da mehr erkennen als ich.
VG
BN
Flash Memory Log TableShowing 1-13 of 13
per page
Log Index Log Time Severity Description
2147483634 2018-Feb-12 14:22:50 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/15 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f15aa4] /lib/libpt hread.so.0(+0x6e64) [0xb6ef0e64] ***** END OF FATAL ERROR *****
2147483635 2018-Feb-12 14:17:45 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/15 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6ee5aa4] /lib/libpt hread.so.0(+0x6e64) [0xb6ec0e64] ***** END OF FATAL ERROR *****
2147483636 2018-Feb-12 14:12:39 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/15 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f8baa4] /lib/libpt hread.so.0(+0x6e64) [0xb6f66e64] ***** END OF FATAL ERROR *****
2147483637 2018-Feb-12 14:07:33 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/15 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f0eaa4] /lib/libpt hread.so.0(+0x6e64) [0xb6ee9e64] ***** END OF FATAL ERROR *****
2147483638 2017-May-10 02:09:44 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/7 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Softw are Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ros () [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6fb1aa4] /lib/libpth read.so.0(+0x6e64) [0xb6f8ce64] ***** END OF FATAL ERROR *****
2147483639 2017-May-10 02:10:29 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/34 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f15aa4] /lib/libpt hread.so.0(+0x6e64) [0xb6ef0e64] ***** END OF FATAL ERROR *****
2147483640 2017-May-10 02:09:42 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/6 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Softw are Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ros () [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6fa7aa4] /lib/libpth read.so.0(+0x6e64) [0xb6f82e64] ***** END OF FATAL ERROR *****
2147483641 2017-May-10 02:12:56 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/11 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f2caa4] /lib/libpt hread.so.0(+0x6e64) [0xb6f07e64] ***** END OF FATAL ERROR *****
2147483642 2017-May-10 02:10:20 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/12 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6ec8aa4] /lib/libpt hread.so.0(+0x6e64) [0xb6ea3e64] ***** END OF FATAL ERROR *****
2147483643 2017-May-10 02:10:21 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/11 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f4eaa4] /lib/libpt hread.so.0(+0x6e64) [0xb6f29e64] ***** END OF FATAL ERROR *****
2147483644 2017-May-10 02:09:42 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/6 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Softw are Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ros () [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6fa2aa4] /lib/libpth read.so.0(+0x6e64) [0xb6f7de64] ***** END OF FATAL ERROR *****
2147483645 2017-May-10 02:20:31 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/11 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Soft ware Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ro s() [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6f5aaa4] /lib/libpt hread.so.0(+0x6e64) [0xb6f35e64] ***** END OF FATAL ERROR *****
2147483646 2018-Feb-10 19:03:30 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi1/0/2 - capability 2 ***** FATAL ERROR ***** Reporting Task: BRMN. Softw are Version: 2.3.0.130 (date May 10 2017 time 01:07:22) ros(HOSTG_fatal_error+0x14) [0x29e9b4] ros(OSSYSG_fatal_error+0x134) [0x7f80d0] ros() [0x624144] ros () [0x80f930] ros() [0x870ca8] ros() [0x8791b0] ros() [0x87ec14] ros() [0x882600] ros() [0x73a468] /lib/libp2linux.so.1(+0x3aa4) [0xb6edeaa4] /lib/libpth read.so.0(+0x6e64) [0xb6eb9e64] ***** END OF FATAL ERROR ***** Hier nun das RAM Memory Log:
Log Index Log Time Severity Description
2147483490 2018-Feb-12 18:16:09 Warning %STP-W-PORTSTATUS: gi1/0/4: STP status Forwarding
2147483491 2018-Feb-12 18:16:04 Informational %LINK-I-Up: gi1/0/4
2147483492 2018-Feb-12 18:15:28 Warning %LINK-W-Down: gi1/0/1
2147483493 2018-Feb-12 18:14:19 Informational %LINK-I-Up: gi1/0/1
2147483494 2018-Feb-12 18:14:19 Warning %STP-W-PORTSTATUS: gi1/0/1: STP status Forwarding
2147483495 2018-Feb-12 18:07:58 Warning %STP-W-PORTSTATUS: gi1/0/23: STP status Forwarding
2147483496 2018-Feb-12 18:07:54 Informational %LINK-I-Up: Vlan XY
2147483497 2018-Feb-12 18:07:54 Informational %LINK-I-Up: Vlan 1
2147483498 2018-Feb-12 18:07:54 Informational %LINK-I-Up: gi1/0/23
2147483499 2018-Feb-12 14:32:09 Warning %LINK-W-Down: Vlan XY
2147483500 2018-Feb-12 14:32:09 Warning %LINK-W-Down: Vlan 1
2147483501 2018-Feb-12 14:32:09 Warning %LINK-W-Down: gi1/0/29
2147483502 2018-Feb-12 14:32:06 Warning %LINK-W-Down: gi1/0/31
2147483503 2018-Feb-12 14:32:05 Informational %LINK-I-Up: gi1/0/31
2147483504 2018-Feb-12 14:32:05 Warning %LINK-W-Down: gi1/0/32
2147483505 2018-Feb-12 14:32:02 Warning %LINK-W-Down: gi1/0/31
2147483506 2018-Feb-12 14:31:59 Warning %LINK-W-Down: gi1/0/36
2147483507 2018-Feb-12 14:31:49 Warning %LINK-W-Down: gi1/0/7
2147483508 2018-Feb-12 14:31:45 Warning %LINK-W-Down: gi1/0/8
2147483509 2018-Feb-12 14:31:41 Warning %STP-W-PORTSTATUS: gi1/0/31: STP status Forwarding
2147483510 2018-Feb-12 14:31:37 Informational %LINK-I-Up: gi1/0/31
2147483511 2018-Feb-12 14:31:34 Warning %LINK-W-Down: gi1/0/9
2147483512 2018-Feb-12 14:31:33 Warning %LINK-W-Down: gi1/0/31
2147483513 2018-Feb-12 14:31:31 Informational %LINK-I-Up: gi1/0/31
2147483514 2018-Feb-12 14:31:30 Warning %LINK-W-Down: gi1/0/10
2147483515 2018-Feb-12 14:31:27 Warning %LINK-W-Down: gi1/0/31
2147483516 2018-Feb-12 14:31:24 Warning %LINK-W-Down: gi1/0/11
2147483517 2018-Feb-12 14:31:21 Warning %LINK-W-Down: gi1/0/12
2147483518 2018-Feb-12 14:31:17 Warning %LINK-W-Down: gi1/0/13
2147483519 2018-Feb-12 14:31:13 Warning %LINK-W-Down: gi1/0/14
2147483520 2018-Feb-12 14:31:11 Warning %LINK-W-Down: gi1/0/15
2147483521 2018-Feb-12 14:28:44 Warning %STP-W-PORTSTATUS: gi1/0/31: STP status Forwarding
2147483522 2018-Feb-12 14:28:40 Informational %LINK-I-Up: gi1/0/31
2147483523 2018-Feb-12 14:28:36 Warning %LINK-W-Down: gi1/0/31
2147483524 2018-Feb-12 14:28:26 Warning %LINK-W-Down: gi1/0/6
2147483525 2018-Feb-12 14:27:03 Warning %LINK-W-Down: gi1/0/26
2147483526 2018-Feb-12 14:27:02 Warning %LINK-W-Down: gi1/0/2
2147483527 2018-Feb-12 14:26:38 Warning %LINK-W-Down: gi1/0/3
2147483528 2018-Feb-12 14:26:33 Informational %INIT-I-Startup: Cold Startup
2147483530 2018-Feb-12 14:25:33 Warning %STP-W-PORTSTATUS: gi1/0/13: STP status Forwarding
2147483531 2018-Feb-12 14:25:32 Warning %STP-W-PORTSTATUS: gi1/0/11: STP status Forwarding
2147483532 2018-Feb-12 14:25:28 Informational %LINK-I-Up: gi1/0/13
2147483533 2018-Feb-12 14:25:27 Informational %LINK-I-Up: gi1/0/11
2147483534 2018-Feb-12 14:25:27 Warning %LINK-W-Down: gi1/0/43
2147483535 2018-Feb-12 14:25:27 Warning %LINK-W-Down: gi1/0/13
2147483536 2018-Feb-12 14:25:26 Warning %LINK-W-Down: gi1/0/11
2147483538 2017-May-10 02:07:45 Warning %STP-W-PORTSTATUS: gi1/0/29: STP status Forwarding
2147483539 2017-May-10 02:07:41 Informational %LINK-I-Up: gi1/0/29
2147483540 2017-May-10 02:07:38 Warning %LINK-W-Down: gi1/0/29
2147483541 2017-May-10 02:07:31 Warning %LINK-W-Down: gi1/0/19
2147483542 2017-May-10 02:07:29 Notice %SYSLOG-N-LOGGING: Logging started.
2147483544 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/43: STP status Forwarding
2147483545 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/36: STP status Forwarding
2147483546 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/32: STP status Forwarding
2147483547 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/31: STP status Forwarding
2147483548 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/29: STP status Forwarding
2147483549 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/26: STP status Forwarding
2147483550 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/19: STP status Forwarding
2147483551 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/15: STP status Forwarding
2147483552 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/13: STP status Forwarding
2147483553 2017-May-10 02:07:13 Warning %STP-W-PORTSTATUS: gi1/0/11: STP status Forwarding
2147483554 2017-May-10 02:07:10 Warning %STP-W-PORTSTATUS: gi1/0/10: STP status Forwarding
2147483555 2017-May-10 02:07:10 Warning %STP-W-PORTSTATUS: gi1/0/9: STP status Forwarding
2147483556 2017-May-10 02:07:10 Warning %STP-W-PORTSTATUS: gi1/0/8: STP status Forwarding
2147483557 2017-May-10 02:07:10 Warning %STP-W-PORTSTATUS: gi1/0/7: STP status Forwarding
2147483558 2017-May-10 02:07:09 Informational %VLAN-I-ReceivedFromVSDP: Voice VLAN updated by VSDP. Voice VLAN-ID XY, VPT 5, DSCP 46
2147483559 2017-May-10 02:07:09 Warning %STP-W-PORTSTATUS: gi1/0/6: STP status Forwarding
2147483560 2017-May-10 02:07:09 Warning %STP-W-PORTSTATUS: gi1/0/3: STP status Forwarding
2147483561 2017-May-10 02:07:09 Warning %STP-W-PORTSTATUS: gi1/0/2: STP status Forwarding
2147483562 2017-May-10 02:07:09 Informational %LINK-I-Up: loopback1
2147483563 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/43
2147483564 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/36
2147483565 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/32
2147483566 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/31
2147483567 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/29
2147483568 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/26
2147483569 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/19
2147483570 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/15
2147483571 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/14
2147483572 2017-May-10 02:07:09 Warning %STP-W-PORTSTATUS: gi1/0/14: STP status Forwarding
2147483573 2017-May-10 02:07:09 Informational %LINK-I-Up: gi1/0/13
2147483574 2017-May-10 02:07:08 Informational %LINK-I-Up: gi1/0/12
2147483575 2017-May-10 02:07:08 Warning %STP-W-PORTSTATUS: gi1/0/12: STP status Forwarding
2147483576 2017-May-10 02:07:08 Informational %LINK-I-Up: Vlan XY
2147483577 2017-May-10 02:07:08 Informational %LINK-I-Up: gi1/0/11
2147483578 2017-May-10 02:07:08 Informational %LINK-I-Up: gi1/0/10
2147483579 2017-May-10 02:07:08 Informational %LINK-I-Up: gi1/0/9
2147483580 2017-May-10 02:07:08 Informational %LINK-I-Up: gi1/0/8
2147483581 2017-May-10 02:07:03 Informational %LINK-I-Up: gi1/0/7
2147483582 2017-May-10 02:07:03 Informational %LINK-I-Up: gi1/0/6
2147483583 2017-May-10 02:07:03 Informational %LINK-I-Up: gi1/0/3
2147483584 2017-May-10 02:07:03 Informational %LINK-I-Up: Vlan 1
2147483585 2017-May-10 02:07:03 Informational %LINK-I-Up: gi1/0/2
2147483586 2017-May-10 02:07:03 Warning %LINK-W-Down: te1/0/4
2147483587 2017-May-10 02:07:03 Warning %LINK-W-Down: te1/0/3
2147483588 2017-May-10 02:07:03 Warning %LINK-W-Down: te1/0/2
2147483589 2017-May-10 02:07:03 Warning %LINK-W-Down: te1/0/1
2147483590 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/48
2147483591 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/47
2147483592 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/46
2147483593 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/45
2147483594 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/44
2147483595 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/43
2147483596 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/42
2147483597 2017-May-10 02:07:03 Warning %LINK-W-Down: gi1/0/41
2147483598 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/40
2147483599 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/39
2147483600 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/38
2147483601 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/37
2147483602 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/36
2147483603 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/35
2147483604 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/34
2147483605 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/33
2147483606 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/32
2147483607 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/31
2147483608 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/30
2147483609 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/29
2147483610 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/28
2147483611 2017-May-10 02:07:02 Warning %LINK-W-Down: gi1/0/27
2147483612 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/26
2147483613 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/25
2147483614 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/24
2147483615 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/23
2147483616 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/22
2147483617 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/21
2147483618 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/20
2147483619 2017-May-10 02:06:59 Warning %LINK-W-Down: gi1/0/19
2147483620 2017-May-10 02:06:57 Warning %LINK-W-Down: gi1/0/18
2147483621 2017-May-10 02:06:57 Warning %LINK-W-Down: gi1/0/17
2147483622 2017-May-10 02:06:57 Informational %Environment-I-FAN-STAT-CHNG: FAN# 3 status changed to operational.
2147483623 2017-May-10 02:06:57 Informational %Environment-I-FAN-STAT-CHNG: FAN# 2 status changed to operational.
2147483624 2017-May-10 02:06:57 Informational %Environment-I-FAN-STAT-CHNG: FAN# 1 status changed to operational.
2147483625 2017-May-10 02:06:55 Warning %LINK-W-Down: gi1/0/16
2147483626 2017-May-10 02:06:55 Warning %LINK-W-Down: gi1/0/15
2147483627 2017-May-10 02:06:54 Warning %LINK-W-Down: gi1/0/14
2147483628 2017-May-10 02:06:54 Warning %LINK-W-Down: gi1/0/13
2147483629 2017-May-10 02:06:52 Warning %LINK-W-Down: gi1/0/12
2147483630 2017-May-10 02:06:52 Warning %LINK-W-Down: gi1/0/11
2147483631 2017-May-10 02:06:50 Warning %LINK-W-Down: gi1/0/10
2147483632 2017-May-10 02:06:50 Warning %LINK-W-Down: gi1/0/9
2147483633 2017-May-10 02:06:49 Warning %LINK-W-Down: gi1/0/8
2147483634 2017-May-10 02:06:49 Warning %LINK-W-Down: gi1/0/7
2147483635 2017-May-10 02:06:48 Warning %LINK-W-Down: gi1/0/6
2147483636 2017-May-10 02:06:48 Warning %LINK-W-Down: gi1/0/5
2147483637 2017-May-10 02:06:47 Warning %LINK-W-Down: gi1/0/4
2147483638 2017-May-10 02:06:47 Warning %LINK-W-Down: gi1/0/3
2147483639 2017-May-10 02:06:47 Warning %LINK-W-Down: gi1/0/2
2147483640 2017-May-10 02:06:47 Warning %LINK-W-Down: gi1/0/1
2147483641 2017-May-10 01:06:45 Informational %SNMP-I-CDBITEMSNUM: Number of startup configuration items loaded: 280
2147483642 2017-May-10 01:06:45 Informational %SNMP-I-CDBITEMSNUM: Number of running configuration items loaded: 280
2147483643 2017-May-10 01:06:45 Informational %NT_poe-I-PoEPowerSourceChange: Active power source set to PS for unit 1
2147483644 2017-May-10 01:06:45 Informational %Entity-I-SEND-ENT-CONF-CHANGE-TRAP: entity configuration change trap.
2147483645 2017-May-10 01:06:37 Informational %MLDP-I-MASTER: Switching to the Master Mode.
2147483646 2017-May-10 01:06:34 Warning %Environment-W-RPS-STAT-MSG: Power supply source changed to Main Power Supply.
2147483647 2017-May-10 01:06:29 Informational %INIT-I-InitCompleted: Initialization task is completed
Soo....
Wenn man mal nach F-DEV_CALC_FAILED Cisco sucht, bist du nicht der einzige... Suche da mal weiter nach.
Dann deaktiviere mal den autosmartport...
Und vorallem, was hast du an den gi1/0/15 angeschlossen gehabt?
Hier würde ich mal schauen, was da los ist. Prüfe auch mal, ob am HP was in den Logs steht, der HP aber anders damit umgeht.
Wenn man mal nach F-DEV_CALC_FAILED Cisco sucht, bist du nicht der einzige... Suche da mal weiter nach.
Dann deaktiviere mal den autosmartport...
Und vorallem, was hast du an den gi1/0/15 angeschlossen gehabt?
Hier würde ich mal schauen, was da los ist. Prüfe auch mal, ob am HP was in den Logs steht, der HP aber anders damit umgeht.
Ich habe Autosmartport erst einmal auf einigen Ports deaktiviert. Auf jeden Fall erkennt er einige Geräte falsch oder bewertet sie falsch, was dann zu Fehlern führt. Aufgefallen ist mir das bei unseren IP-Telefonen (Avaya 9608G), die über einen eingebauten Switchport verfügen und an die ein Gerät angeschlossen war. Dann hat er die Telefone immer als Switch erkannt, was dann dazu führte, dass sie im falschen VLAN landeten. Wurde der Switch des Telefons nicht benutzt, hat er die Geräte korrekt als "IP-Phone + Desktop" einsortiert und ins richtige VLAN gesteckt. Ich hoffe, das nachträgliche Anschließen eines Geräts an den Telefon-Switch ändert nicht den Smartport Type.
Ob das jetzt der Grund für die Abstürze war, ist mir noch nicht ganz klar.
Ich vermute, dass ich an den gi1/0/15 eines der IP-Telefone angeschlossen hatte, da ich auf den oberen Ports (4-16) nur die Kabel gepatcht habe, deren Farbe mir sagte: Das ist ein IP-Telefon. Auf den unteren Ports (28 ff.) habe ich die PCs gepatcht.
Morgen geht es weiter mit dem Patchen der restlichen Dosen. Ich bin gespannt, ob er bei Ports ohne angeschlossene Endgeräte auch abstürzt.
Ob das jetzt der Grund für die Abstürze war, ist mir noch nicht ganz klar.
Ich vermute, dass ich an den gi1/0/15 eines der IP-Telefone angeschlossen hatte, da ich auf den oberen Ports (4-16) nur die Kabel gepatcht habe, deren Farbe mir sagte: Das ist ein IP-Telefon. Auf den unteren Ports (28 ff.) habe ich die PCs gepatcht.
Morgen geht es weiter mit dem Patchen der restlichen Dosen. Ich bin gespannt, ob er bei Ports ohne angeschlossene Endgeräte auch abstürzt.
Stelle gerade fest, dass ich ja schon am Anfang geschrieben habe, dass, als der Switch heute das erste Mal abstürzte, an dem Port ein IP-Telefon (Avaya 9608G) hing. Am Switchport des Telefons war allerdings kein Endgerät angeschlossen, sondern es steckte nur ein Patchkabel. Vielleicht ist das der Grund.
Liegt das an einer Einstellung des Cisco-Switches oder ist er defekt?
Neueste Firmware hast du auf das gerät hoffentlich geflasht ??https://software.cisco.com/download/release.html?mdfid=286288281&sof ...
Was noch sein kann ist die Tatsache das du den Switch ggf. PoE seitig überlastest. Stelle ggf. die Power Class deine Endgeräte fest ein. Viele Endgeräte übertragen beim Verbindungsaufbau sehr oft die falsche oder keine korrekte Power Class. Der Switch reserviert dann die Maximalleistung dafür obwohl das nicht immer sein muss.
Um sich zu schützen rebootet der Switch dann oder schaltete die Stromversorgung weg sollte er Budget mässig überbucht werden.
Das andere ist das du Störspannungen entweder über die 220V Stromversorgung oder eines der LAN Ports bekommst. Das kannst du nur sukzessive testen. Möglich auch das die Auweia Telefone eine falsche PoE Negotiation machen oder per LLDP falsche PoE Daten senden.
Möglich ist aber auch ein DOA (Dead on Arrival) also ein technischer Defekt. Bei letzuterem hilft dann nur ein RMA.
In jedem Falls solltest du aber IMMER zuerst die aktuellste Firmware flashen bevor man in Produktion geht !
Port 15 würde mich auch interessieren. Was bei PoE natürlich immer mal sein kann ist, dass ein Gerät sich nicht an PoE Standards hält. Das sollte zwar nicht, kann aber zum Absturz führen. Smartport würde ich aufjedenfall komplett deaktivieren. Hat bei mir auch nur für Probleme gesorgt.
Hallo zusammen,
nachfolgend findet ihr einige Testergebnisse.
Ich hatte am Montagabend alle bisher am HP angeschlossenen Geräte wieder auf den Cisco umgestöpselt und es lief am Dienstag auch so wie gewünscht. Abends habe ich dann, wie geplant, erst einmal nur zwei weitere Ports auf dem Switch gepatcht (gi1/0/18 und gi1/0/42) und an gi1/0/18 eines der Avaya 9608G über PoE angeschlossen.
1. Test:
Die Port Settings waren 1.000 MBit/Full Duplex, PoE enabled (Default-Einstellung) und die Smartport Application Method auf "Auto Smartport" eingestellt. Am Avaya Switchport hing noch ein Patchkabel ohne angeschlossenes Gerät. Ergebnis: Switch stürzte ab mit der schon o.g. FATAL ERROR Meldung, nur halt diesmal für gi1/0/18. In einem weiteren Test mit den gleichen Einstellungen, aber ohne Patchkabel am Avaya Switchport, stürzte der Cisco trotzdem ab. Damit kann man das Patchkabel als Ursache m.E. ausschließen.
2. Test:
Gleiches Setting wie beim ersten Test, aber Smartport Application Method auf "Disabled" gesetzt. Beim ersten Mal stürzte der Switch wieder ab, nach dem Reboot lief er aber anscheinend erst einmal stabil. Da hatte ich mich aber zu früh gefreut: Nachdem ich das Telefon wieder an seinen ursprünglichen Platz gestellt und angeschlossen hatte (gi1/0/9), ging der Spaß von vorn los.
3. Test:
Port Setting von gi1/0/9 wie beim ersten Test, bis auf Smartport Type = "IP Phone + Desktop" anstatt "Default". Nach Anschluss des IP Phones erkennt der Cisco das Telefon per "Auto Smartport" als Switch und findet daher nicht das korrekte Voice VLAN. Das Telefon bleibt dabei in einer Rebootschleife hängen.
Anschließend habe ich den Persistent Status in "Disabled" geändert, was aber zu keiner Änderung in der Erkennung führte.
Nun habe ich die Smartport Application Method in "Disabled" geändert, was den Smartport Type auf "Default" zurücksetzte, mit dem Ergebnis, dass das IP Phone das korrekte VLAN gefunden hat.
Dann habe ich die Smartport Application Method wieder in "Auto Smartport" geändert. Das IP Phone wurde nun als "IP Phone + Desktop" erkannt und der Switch stürzte wieder ab.
Daraufhin habe ich Auto Smartport am gi1/0/9 wieder deaktiviert und das Telefon abgeklemmt.
Jetzt werden meine Aufzeichnungen etwas dünner, daher kann es sein, dass Zwischenschritte fehlen (war ja schon mitten in der Nacht).
Ich habe mir noch notiert: Port gi1/0/11: "IP Phone + Desktop", Smartport Application Method: "Static", Persistent Status: "Enabled". Switch stürzt ab. An diesem Port hing ein anderes IP Phone.
Nun konnte ich plötzlich nicht mal mehr die Telefonanlage im Voice VLAN vom Rechner aus erreichen, obwohl ich an den VLAN-Einstellungen keine Änderungen vorgenommen hatte.
Leicht entnervt habe ich dann alle IP-Telefone abgeklemmt, einen Factory Reset durchgeführt, das Voice VLAN neu eingerichtet und die Telefone wieder angeschlossen.
An den Smartport-Einstellungen habe ich keine Änderungen vorgenommen. Erstaunlicherweise wurden nun alle Telefone korrekt als "IP Phone + Desktop" erkannt, bis auf die beiden Konferenztelefone (Avaya B179), die als Smartport Type "Default" behalten haben. Trotzdem wurden sie richtigerweise in das Voice VLAN einsortiert.
Ich vermute nun, dass ich beim ersten Mal eine Einstellung vorgenommen habe, die das ganze Verhalten mit verursacht hat, ohne dass ich jetzt wüsste, welche das gewesen sein könnte. Oder aber der Switch hat durch diese Abstürze seine Konfiguration zerschossen (meine Vermutung ab dem dritten Test).
Die Firmware werde ich in den nächsten Tagen updaten.
nachfolgend findet ihr einige Testergebnisse.
Ich hatte am Montagabend alle bisher am HP angeschlossenen Geräte wieder auf den Cisco umgestöpselt und es lief am Dienstag auch so wie gewünscht. Abends habe ich dann, wie geplant, erst einmal nur zwei weitere Ports auf dem Switch gepatcht (gi1/0/18 und gi1/0/42) und an gi1/0/18 eines der Avaya 9608G über PoE angeschlossen.
1. Test:
Die Port Settings waren 1.000 MBit/Full Duplex, PoE enabled (Default-Einstellung) und die Smartport Application Method auf "Auto Smartport" eingestellt. Am Avaya Switchport hing noch ein Patchkabel ohne angeschlossenes Gerät. Ergebnis: Switch stürzte ab mit der schon o.g. FATAL ERROR Meldung, nur halt diesmal für gi1/0/18. In einem weiteren Test mit den gleichen Einstellungen, aber ohne Patchkabel am Avaya Switchport, stürzte der Cisco trotzdem ab. Damit kann man das Patchkabel als Ursache m.E. ausschließen.
2. Test:
Gleiches Setting wie beim ersten Test, aber Smartport Application Method auf "Disabled" gesetzt. Beim ersten Mal stürzte der Switch wieder ab, nach dem Reboot lief er aber anscheinend erst einmal stabil. Da hatte ich mich aber zu früh gefreut: Nachdem ich das Telefon wieder an seinen ursprünglichen Platz gestellt und angeschlossen hatte (gi1/0/9), ging der Spaß von vorn los.
3. Test:
Port Setting von gi1/0/9 wie beim ersten Test, bis auf Smartport Type = "IP Phone + Desktop" anstatt "Default". Nach Anschluss des IP Phones erkennt der Cisco das Telefon per "Auto Smartport" als Switch und findet daher nicht das korrekte Voice VLAN. Das Telefon bleibt dabei in einer Rebootschleife hängen.
Anschließend habe ich den Persistent Status in "Disabled" geändert, was aber zu keiner Änderung in der Erkennung führte.
Nun habe ich die Smartport Application Method in "Disabled" geändert, was den Smartport Type auf "Default" zurücksetzte, mit dem Ergebnis, dass das IP Phone das korrekte VLAN gefunden hat.
Dann habe ich die Smartport Application Method wieder in "Auto Smartport" geändert. Das IP Phone wurde nun als "IP Phone + Desktop" erkannt und der Switch stürzte wieder ab.
Daraufhin habe ich Auto Smartport am gi1/0/9 wieder deaktiviert und das Telefon abgeklemmt.
Jetzt werden meine Aufzeichnungen etwas dünner, daher kann es sein, dass Zwischenschritte fehlen (war ja schon mitten in der Nacht).
Ich habe mir noch notiert: Port gi1/0/11: "IP Phone + Desktop", Smartport Application Method: "Static", Persistent Status: "Enabled". Switch stürzt ab. An diesem Port hing ein anderes IP Phone.
Nun konnte ich plötzlich nicht mal mehr die Telefonanlage im Voice VLAN vom Rechner aus erreichen, obwohl ich an den VLAN-Einstellungen keine Änderungen vorgenommen hatte.
Leicht entnervt habe ich dann alle IP-Telefone abgeklemmt, einen Factory Reset durchgeführt, das Voice VLAN neu eingerichtet und die Telefone wieder angeschlossen.
An den Smartport-Einstellungen habe ich keine Änderungen vorgenommen. Erstaunlicherweise wurden nun alle Telefone korrekt als "IP Phone + Desktop" erkannt, bis auf die beiden Konferenztelefone (Avaya B179), die als Smartport Type "Default" behalten haben. Trotzdem wurden sie richtigerweise in das Voice VLAN einsortiert.
Ich vermute nun, dass ich beim ersten Mal eine Einstellung vorgenommen habe, die das ganze Verhalten mit verursacht hat, ohne dass ich jetzt wüsste, welche das gewesen sein könnte. Oder aber der Switch hat durch diese Abstürze seine Konfiguration zerschossen (meine Vermutung ab dem dritten Test).
Die Firmware werde ich in den nächsten Tagen updaten.
Sorry aber ich kann deine "Tests" nicht wirklich nachvollziehen. Warum so kompliziert? Warum lässt du das Smartport gedöns bei Test 1 an?
Das macht die Fehleranalyse unnötig schwierig. Man nimmt den Switch in Betrieb und steckt Port für Port dazu. Und dabei halt immer ein Auge ins Log File. Und nochmal: Auto Smartport gehört aus!
Zitat von @Bodennebel:
Ich hatte am Montagabend alle bisher am HP angeschlossenen Geräte wieder auf den Cisco umgestöpselt und es lief am Dienstag auch so wie gewünscht.
Ich hatte am Montagabend alle bisher am HP angeschlossenen Geräte wieder auf den Cisco umgestöpselt und es lief am Dienstag auch so wie gewünscht.
Das macht die Fehleranalyse unnötig schwierig. Man nimmt den Switch in Betrieb und steckt Port für Port dazu. Und dabei halt immer ein Auge ins Log File. Und nochmal: Auto Smartport gehört aus!
Hallo zusammen,
zum Abschluss noch ein kurzes Feedback von mir: Ich habe eure Tipps beherzigt und nach dem Factory Reset den Switch auf den aktuellen Firmwarestand gebracht. Seitdem läuft er trotz aktivierten Auto Smartport ohne Probleme.
Vielen Dank für eure Hinweise und Anregungen!
BN
zum Abschluss noch ein kurzes Feedback von mir: Ich habe eure Tipps beherzigt und nach dem Factory Reset den Switch auf den aktuellen Firmwarestand gebracht. Seitdem läuft er trotz aktivierten Auto Smartport ohne Probleme.
Vielen Dank für eure Hinweise und Anregungen!
BN
Das sollte eigentlich IMMER die Standardprozedur eines Netzwerkers sein BEVOR man Geräte in Produktion bringt.
Gut wenn es nun rennt wie es soll !
Gut wenn es nun rennt wie es soll !
Hallo zusammen,
ich muss das Thema leider nochmal aufrollen.
Wir haben bei uns für den dezentralen Einsatz seit kurzer Zeit die Cisco SG350-10MP im Einsatz. Fünf von denen haben wir aktuell im Einsatz, jedoch laufen nur in einem Büro auch Telefone mit PoE darüber. Die Telefone sind von Avaya und der Uplink auf Port 10 kommt von einem Avaya Switch (eingeführt durch einen ehemaligen Mitarbeitern), welcher wiederrum den Uplink vom Cisco Core bekommt.
Mein Problem ist, dass meiner Meinung nach alle hier aufgeführten Tips schon erfüllt sind.
Als guter Admin, ist natürlich die neueste Firmware installiert ;)
Autosmartport und damit auch Auto Voice VLAN haben wir deaktiviert, da die Ports auf denen die Telefone liefen sich sonst automatisch zu Trunks gemacht haben. Das wollte ich nicht, oder ist das normal?
Jedenfalls ist das, wie gesagt, deaktiviert.
Bisher hatte ich nur im Basic Mode gearbeitet, da der alles geboten hat, was mich interessiert, allerdings habe ich jetzt unter Smartport noch mehr Einstellungen gefunden, kenne die aber nicht und weiß nicht, ob ich die ändern sollte. Der Screenshot ist im Anhang.
Meine Fehlermeldung, die ich schon für verschiedene Ports bekommen habe, allerdings inhaltlich immer die gleiche ist (hier jetzt für Port 4):
2147483640 2018-May-08 05:41:02 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi4 - capability 2 * FATAL ERROR * Reporting Task: BRMN. Software Version: 2.3.5.63 (date Aug 20 2017 time 19:03:04) ros(HOSTG_fatal_error+0x14) [0x2a8b78] ros(OSSYSG_fatal_error+0x134) [0x8226d8] ros() [0x64248c] ros() [0 x83a7b8] ros() [0x89e600] ros() [0x8a73c8] ros() [0x8ab774] ros() [0x8b07ac] ros() [0x75de78] /lib/libp2linux.so.1(+0x3aa4) [0xb6f5faa4] /lib/libpthread. so.0(+0x6e64) [0xb6f3ae64] * END OF FATAL ERROR *
Die Meldung kommt wie gesagt zu verschiedenen Ports, allerdings meines Wissens nur Ports an denen ein Avaya Telefon hängt.
Ingesamt laufen auf dem Switch zwei PCs, drei Telefone und zwei Drucker.
Hoffe mir kann noch jemand helfen.
P.S. Resetet wurde auch schon. Sogar schon Switch getauscht und identisch eingerichtet. Danach kam der Fehler ewig nicht mehr, jetzt aber doch wieder auf dem Tauschgerät.
ich muss das Thema leider nochmal aufrollen.
Wir haben bei uns für den dezentralen Einsatz seit kurzer Zeit die Cisco SG350-10MP im Einsatz. Fünf von denen haben wir aktuell im Einsatz, jedoch laufen nur in einem Büro auch Telefone mit PoE darüber. Die Telefone sind von Avaya und der Uplink auf Port 10 kommt von einem Avaya Switch (eingeführt durch einen ehemaligen Mitarbeitern), welcher wiederrum den Uplink vom Cisco Core bekommt.
Mein Problem ist, dass meiner Meinung nach alle hier aufgeführten Tips schon erfüllt sind.
Als guter Admin, ist natürlich die neueste Firmware installiert ;)
Autosmartport und damit auch Auto Voice VLAN haben wir deaktiviert, da die Ports auf denen die Telefone liefen sich sonst automatisch zu Trunks gemacht haben. Das wollte ich nicht, oder ist das normal?
Jedenfalls ist das, wie gesagt, deaktiviert.
Bisher hatte ich nur im Basic Mode gearbeitet, da der alles geboten hat, was mich interessiert, allerdings habe ich jetzt unter Smartport noch mehr Einstellungen gefunden, kenne die aber nicht und weiß nicht, ob ich die ändern sollte. Der Screenshot ist im Anhang.
Meine Fehlermeldung, die ich schon für verschiedene Ports bekommen habe, allerdings inhaltlich immer die gleiche ist (hier jetzt für Port 4):
2147483640 2018-May-08 05:41:02 Emergency %AUTOSMARTPORT-F-DEV_CALC_FAILED: XDP device type calculation failed: interface gi4 - capability 2 * FATAL ERROR * Reporting Task: BRMN. Software Version: 2.3.5.63 (date Aug 20 2017 time 19:03:04) ros(HOSTG_fatal_error+0x14) [0x2a8b78] ros(OSSYSG_fatal_error+0x134) [0x8226d8] ros() [0x64248c] ros() [0 x83a7b8] ros() [0x89e600] ros() [0x8a73c8] ros() [0x8ab774] ros() [0x8b07ac] ros() [0x75de78] /lib/libp2linux.so.1(+0x3aa4) [0xb6f5faa4] /lib/libpthread. so.0(+0x6e64) [0xb6f3ae64] * END OF FATAL ERROR *
Die Meldung kommt wie gesagt zu verschiedenen Ports, allerdings meines Wissens nur Ports an denen ein Avaya Telefon hängt.
Ingesamt laufen auf dem Switch zwei PCs, drei Telefone und zwei Drucker.
Hoffe mir kann noch jemand helfen.
P.S. Resetet wurde auch schon. Sogar schon Switch getauscht und identisch eingerichtet. Danach kam der Fehler ewig nicht mehr, jetzt aber doch wieder auf dem Tauschgerät.
Der Fehler sieht recht fatal aus. Das ist kein Trivial Fehler der aus einer falschen Konfig resultiert sondern sieht eher nach einem SW Bug aus.
Das Cisco Supportforum blieb auch still diesbezüglich:
https://supportforums.cisco.com/t5/small-business-switches/autosmartport ...
Du solltest einen Case im Cisco TAC aufmachen dafür !
Das Cisco Supportforum blieb auch still diesbezüglich:
https://supportforums.cisco.com/t5/small-business-switches/autosmartport ...
Du solltest einen Case im Cisco TAC aufmachen dafür !
1
Unser Consulting hat jetzt CDP auf den Ports mit den Avaya Telefonen deaktiviert. Mal sehen, ob es hilft, andernfalls werden wir einen Case bei Cisco aufmachen.
Wenn die Auweias gar kein CDP supporten oder verstehen wird das wenig bringen.
CDP solltest du so oder so komplett aus lassen, denn das ist mehr oder minder tod, da ein Cisco proprietäres Protokoll.
Wenn überhaupt, dann solltest du logischerweise immer nur ein einziges Infrastruktur Protokoll laufen lassen und das ist in heterogenen Umgebungen wie deiner IMMER der Standard LLDP ! Nichts anderes.
Niemals also 2 Protokolle zugleich.
Intuitiv ist es also nicht falsch das zu deaktivieren. Aber wenn dann global in der Konfig und nicht nur auf einselnen Ports !
CDP solltest du so oder so komplett aus lassen, denn das ist mehr oder minder tod, da ein Cisco proprietäres Protokoll.
Wenn überhaupt, dann solltest du logischerweise immer nur ein einziges Infrastruktur Protokoll laufen lassen und das ist in heterogenen Umgebungen wie deiner IMMER der Standard LLDP ! Nichts anderes.
Niemals also 2 Protokolle zugleich.
Intuitiv ist es also nicht falsch das zu deaktivieren. Aber wenn dann global in der Konfig und nicht nur auf einselnen Ports !
