7
Cisco Catalyst 3560 PoE - Probleme mit Fremdgeräten z.B. Polycom-Telefonen
Hallo zusammen,
ich hoffe der Beitrag ist an der richtigen Stelle, da es sich um die Verquickung mehrerer möglicher Punkte handelt.
folgendes Umfeld:
Wir setzen diverse Cisco-Switche ein, u.a. Catalyst 3560, 3560v2 und 4506.
Nach Einführung diverser VoIP-Engeräte (Cisco und Polycom) wurden die Geräte auf die aktuell benötigten Featuires gebracht:
- Update auf 12.2(54) bzw. 12.2.(55) ipbasek9 - hier volle Unterstützung des lldp-Protokolls - Standard zum Cisco propreitären cdp
- lldp aktiviert
Stand:
Voip Telefone von Cisco und Polycom funktionieren. Voip-Vlans, Kaskadierung von PCs am Telefon., cdp bei Cisco und lldp bei Polycom zur Erkennung des Endgerätes ebenso.
PoE-Klassen werden richtig erkannt.
Cisco verwendet ein eigenes PoE-Protokoll, der Standard verwendet 802.1af.
Die eingesetzten Switche - speziell reduziert auf die 3560 und 3560v2 unterstützen beide Protokolltypen.
Problem:
Die Polycom-Telefone verfallen bei länger Nicht-Nutzung in eine Art Standby-Modus (s.unten: 3 Watt vs. 7 Watt)
Wird dann der Hörer abgenommen oder eine Taste gedrückt, rebootet das Telefon.
Dies passiert nicht bei externen PoE-Adaptern ,aber bei Speisung über die PoE-Switchports.
Bisherige Recherche:
Es scheint wohl noch Unterschiede zwischen den implementierten IEEE 802.1af-Protokoll-Details zu geben.
Als mögliche Lösung findet man in diversen Foren und Referenzen folgendes Kommando, welches man auf den Interfacen der Switche angeben soll:
power inline delay .... - der Port hält PoE eine gewisse Zeit aufrecht, auch wenn der Link kurz abbricht etc. (z.B. bei Boot-Prozessen oder Status-Änderungen von Endgeräten)
Dieses Kommando ist aber bei den 3560-Switchen nicht verfügbar.
Fragen:
1. Ist hierfür ein spezielles Featureset notwendig ?
2. Was ist ein möglicher Workaround ?
Vielen Dank im Voraus für eure Hilfe.
xw
Anhang:
show power inline fa0/1 - im "Standby"
Interface Admin Oper Power Device Class Max
(Watts)
------ ---------- ------- ------------------- ----- ----
Fa0/1 auto on 3.0 Ieee PD 2 15.4
Interface AdminPowerMax AdminConsumption
(Watts) (Watts)
--------------- --------------------
Fa0/1 15.4 15.4
show power inline fa0/1 - im "Betrieb"
Interface Admin Oper Power Device Class Max
(Watts)
------ ---------- ------- ------------------- ----- ----
Fa0/1 auto on 7.0 Ieee PD 2 15.4
Interface AdminPowerMax AdminConsumption
(Watts) (Watts)
--------------- --------------------
Fa0/1 15.4 15.4
ich hoffe der Beitrag ist an der richtigen Stelle, da es sich um die Verquickung mehrerer möglicher Punkte handelt.
folgendes Umfeld:
Wir setzen diverse Cisco-Switche ein, u.a. Catalyst 3560, 3560v2 und 4506.
Nach Einführung diverser VoIP-Engeräte (Cisco und Polycom) wurden die Geräte auf die aktuell benötigten Featuires gebracht:
- Update auf 12.2(54) bzw. 12.2.(55) ipbasek9 - hier volle Unterstützung des lldp-Protokolls - Standard zum Cisco propreitären cdp
- lldp aktiviert
Stand:
Voip Telefone von Cisco und Polycom funktionieren. Voip-Vlans, Kaskadierung von PCs am Telefon., cdp bei Cisco und lldp bei Polycom zur Erkennung des Endgerätes ebenso.
PoE-Klassen werden richtig erkannt.
Cisco verwendet ein eigenes PoE-Protokoll, der Standard verwendet 802.1af.
Die eingesetzten Switche - speziell reduziert auf die 3560 und 3560v2 unterstützen beide Protokolltypen.
Problem:
Die Polycom-Telefone verfallen bei länger Nicht-Nutzung in eine Art Standby-Modus (s.unten: 3 Watt vs. 7 Watt)
Wird dann der Hörer abgenommen oder eine Taste gedrückt, rebootet das Telefon.
Dies passiert nicht bei externen PoE-Adaptern ,aber bei Speisung über die PoE-Switchports.
Bisherige Recherche:
Es scheint wohl noch Unterschiede zwischen den implementierten IEEE 802.1af-Protokoll-Details zu geben.
Als mögliche Lösung findet man in diversen Foren und Referenzen folgendes Kommando, welches man auf den Interfacen der Switche angeben soll:
power inline delay .... - der Port hält PoE eine gewisse Zeit aufrecht, auch wenn der Link kurz abbricht etc. (z.B. bei Boot-Prozessen oder Status-Änderungen von Endgeräten)
Dieses Kommando ist aber bei den 3560-Switchen nicht verfügbar.
Fragen:
1. Ist hierfür ein spezielles Featureset notwendig ?
2. Was ist ein möglicher Workaround ?
Vielen Dank im Voraus für eure Hilfe.
xw
Anhang:
show power inline fa0/1 - im "Standby"
Interface Admin Oper Power Device Class Max
(Watts)
------ ---------- ------- ------------------- ----- ----
Fa0/1 auto on 3.0 Ieee PD 2 15.4
Interface AdminPowerMax AdminConsumption
(Watts) (Watts)
--------------- --------------------
Fa0/1 15.4 15.4
show power inline fa0/1 - im "Betrieb"
Interface Admin Oper Power Device Class Max
(Watts)
------ ---------- ------- ------------------- ----- ----
Fa0/1 auto on 7.0 Ieee PD 2 15.4
Interface AdminPowerMax AdminConsumption
(Watts) (Watts)
--------------- --------------------
Fa0/1 15.4 15.4
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: 167000
Url: https://administrator.de/contentid/167000
Ausgedruckt am: 26.11.2024 um 07:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
evenutell kommst du mit einem
weiter, dann sollte der PoE Port ständig mit Power versorgt werden und deine Polycom Geräte dürften auch wieder aufwachen
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/rele ...
brammer
evenutell kommst du mit einem
power inline static [max 15400] weiter, dann sollte der PoE Port ständig mit Power versorgt werden und deine Polycom Geräte dürften auch wieder aufwachen
http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/rele ...
brammer
Hallo brammer,
die 'static'-option bedeutet nur eine "Reservierung" für den Switch --> Vorhaltung der Leistung im "Power-Bu7dget" des Switches. Die Aushandlung der aktuell benötigten Leistung des Ports geschieht hier auch dynamisch.
Diese Ports werden praktisch "bevorzug" versorgt wenn das power-Budget überzogen wird.
Es gäbe zwar noch die Möglichkeit feste consupmtions zu definieren, allerdings wird von allen statischen power-Einstellungen dringend abgeraten. - teilweise mit Garantieverlust !
Also die vorhandenen optionen habe ich mir alle schon angeschaut. Wenn ich nichts übersehen habe ....
Trotzdem danke für das feedback.
Vielleicht findet ja noch jemand was. Ansonsten muss ich doch mal einen Case aufmachen.
die 'static'-option bedeutet nur eine "Reservierung" für den Switch --> Vorhaltung der Leistung im "Power-Bu7dget" des Switches. Die Aushandlung der aktuell benötigten Leistung des Ports geschieht hier auch dynamisch.
Diese Ports werden praktisch "bevorzug" versorgt wenn das power-Budget überzogen wird.
Es gäbe zwar noch die Möglichkeit feste consupmtions zu definieren, allerdings wird von allen statischen power-Einstellungen dringend abgeraten. - teilweise mit Garantieverlust !
Also die vorhandenen optionen habe ich mir alle schon angeschaut. Wenn ich nichts übersehen habe ....
Trotzdem danke für das feedback.
Vielleicht findet ja noch jemand was. Ansonsten muss ich doch mal einen Case aufmachen.
Hallo,
wie sieht es den auf Seiten der Polycom Geräte aus?
Kann man diesen Geräte den Wechsel in den Standby nicht abgewöhnen?
brammer
wie sieht es den auf Seiten der Polycom Geräte aus?
Kann man diesen Geräte den Wechsel in den Standby nicht abgewöhnen?
brammer
Hallo zusammen,
es gibt wohl noch Unterschiede bei versc hiedenen Herstellen, wass das power-mangemant angeht.
Wir haben momentan einen workaround für dieses problem.
Auf allen betroffenen Interaces der Cisco-Switche, folgendess konfigurieren:
no lldp med-tlv-select power-management
Seitdem laufen jetzt alles Geräte ohne Probleme.
Da ich nicht glaube, dass bei allen herstellern diese probleme in naher Zukunft gelöst werden, werde ich das erstmal als Lösung ansehen.
Hoffe dies hilft anderen weiter.
Gruß
Olli
es gibt wohl noch Unterschiede bei versc hiedenen Herstellen, wass das power-mangemant angeht.
Wir haben momentan einen workaround für dieses problem.
Auf allen betroffenen Interaces der Cisco-Switche, folgendess konfigurieren:
no lldp med-tlv-select power-management
Seitdem laufen jetzt alles Geräte ohne Probleme.
Da ich nicht glaube, dass bei allen herstellern diese probleme in naher Zukunft gelöst werden, werde ich das erstmal als Lösung ansehen.
Hoffe dies hilft anderen weiter.
Gruß
Olli
Hallo,
der Workaround spricht aber ja dafür, das die Polycom Geräte mit dem LLDP nicht umgehen können.
Hat sich Polycom als Hersteller dazu mal geäußert?
brammer
der Workaround spricht aber ja dafür, das die Polycom Geräte mit dem LLDP nicht umgehen können.
Hat sich Polycom als Hersteller dazu mal geäußert?
brammer
man ist da dabei die Protokolldifferenzen anzupassen.
Gut -- lldp funktioniert soweit - aber eben die Details sind das Problem.
Leider ist IEEE ja auch nur mehr eine "Empfehlung" als eine Norm
Wenn es hier mal "richtige" Standards wie eine ISO- oder EIA/TIA-Norm geben würde, wäre das echt mal ein Fortschritt....
Gut -- lldp funktioniert soweit - aber eben die Details sind das Problem.
Leider ist IEEE ja auch nur mehr eine "Empfehlung" als eine Norm
Wenn es hier mal "richtige" Standards wie eine ISO- oder EIA/TIA-Norm geben würde, wäre das echt mal ein Fortschritt....
Hallo,
Erfahrungsgemäß ist es so das die kleinen sich an die großen anpassen.
Und eigentlich bräuchte sich nur jeder Hersteller an die IEEE Empfehlungen halten dann würde vieles Funktionieren...
Träumen darf man ja...
brammer
Erfahrungsgemäß ist es so das die kleinen sich an die großen anpassen.
Und eigentlich bräuchte sich nur jeder Hersteller an die IEEE Empfehlungen halten dann würde vieles Funktionieren...
Träumen darf man ja...
brammer
