In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument wird die Peer Firmware Sharing (PFS)-Funktion des IP-Telefons beschrieben, die es IP-Telefonen an Remote-Standorten ermöglicht, Firmware-Dateien untereinander auszutauschen, im Gegensatz zu der herkömmlichen Methode des Firmware-Upgrades für IP-Telefone, bei der der Trivia File Tranfer Protocol (TFTP)-Server Firmware-Dateien an jedes Telefon sendet.
Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:
Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:
Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.
Im herkömmlichen Firmware-Upgrade-Prozess muss der TFTP-Server mit jedem Telefon einzeln kommunizieren und die Upgrade-Dateien gleichzeitig an dieses Telefon senden. Betrachten Sie jedoch ein Szenario, in dem sich 1000 Telefone an einem Remote-Standort befinden und der TFTP-Server im Hauptsitz ca. 15.000 km entfernt ist. In diesem Fall sind Telefone über das Wide Area Network (WAN) und in einer großen Anzahl mit dem Server verbunden. Das Firmware-Upgrade für diese Telefone nimmt also sehr viel Zeit in Anspruch.
PFS ermöglicht es IP-Telefonen an Remote-Standorten, die Firmware-Dateien untereinander auszutauschen, wodurch Bandbreite gespart wird, wenn der Upgrade-Prozess stattfindet. Diese Funktion verwendet das Cisco Peer-to-Peer Distribution Protocol, ein proprietäres Protokoll von Cisco, das zur Erstellung einer Peer-to-Peer-Hierarchie von Geräten verwendet wird. Das Cisco Peer-to-Peer Distribution Protocol wird auch zum Kopieren von Firmware oder anderen Dateien von Peer-Geräten auf die benachbarten Geräte verwendet.
PFS ist in der Telefon-Firmware-Version 8.3(1) (und höher) enthalten, die als Teil der CUCM 6.0-Version ausgeliefert wird. Sie gilt für Cisco IP-Telefone der 3. Generation, die Folgendes umfassen:
Hinweis: PFS ist weder für 7960- oder 7940-Telefone der zweiten Generation noch für OEM-Telefone wie die Tandberg-Videotelefone geeignet.
Im Folgenden sind einige der wichtigsten Vorteile von PFS gegenüber der herkömmlichen Upgrade-Methode aufgeführt:
Abbildung 1: Peer Firmware Sharing Distribution Hierarchie
Abbildung 2: Hierarchische Unterschiede zwischen herkömmlichen Upgrade-Methoden und PFS
Abbildung 2 a) Herkömmliches Firmware-Upgrade
Abbildung 2 (b). PFS
Nur das PFS-Feld muss den Wert für eines dieser Elemente in absteigender Reihenfolge der Rangfolge aktivieren, wie im Bild gezeigt:
1. Telefonkonfigurationsseite jedes Remote-Geräts.
2. Allgemeines Telefonprofil.
3. Konfiguration des Enterprise-Telefons
Dies ist ein Auszug aus den Konsolenprotokollen vom Root-Telefon, um zu bestätigen, dass PFS hier funktioniert:
"DBG 02:19:22.634167 DLoad: +++ fd=7 Listening on peer TCP port 4051"
Weist darauf hin, dass das Telefon den Peer-to-Peer-Prozess startet und bereit ist, die Handshake-Pakete zu überwachen, um eine Peer-to-Peer-Struktur einzurichten, bevor die Firmware freigegeben wird:
NOT 02:19:22.634945 DLoad: ^.idl_child.c-openUDPPort NOT 02:19:22.664131 DLoad: |parent=-1><fd[0]=-1 fd[1]=-1 FULL=0
"NOT 02:19:23.161938 DLoad: ^.idl_protocol.c-sendBroadcastOffer"
Telefon sendet eine Broadcast Offer-Nachricht an alle Peers, wenn es zum Root wird:
"NF 02:19:23.162700 DLoad: XID080027F8 TxBdcst ClaimRoot(tent): map=ff9d7cb9 strength=31d4d43d "
Weist darauf hin, dass das Telefon begonnen hat, sich im Subnetz selbst als Ursprung der Peer-to-Peer-Freigabe zu behaupten:
"NOT 02:19:23.410198 DLoad: ^.idl_timeout.c-doTimeout DBG 02:19:23.410963 DLoad: Timeout XID080027F8 hier=ClaimRoot(tent) NOT 02:19:23.411644 DLoad: ^.idl_protocol.c-sendBroadcastOffer INF 02:19:23.411925 DLoad: XID080027F8 TxBdcst Ad 1: ClaimRoot(tent) NOT 02:19:23.660235 DLoad: ^.idl_timeout.c-doTimeout DBG 02:19:23.661014 DLoad: Timeout XID080027F8 hier=ClaimRoot(tent) NOT 02:19:23.661772 DLoad: ^.idl_protocol.c-sendBroadcastOffer INF 02:19:23.662527 DLoad: XID080027F8 TxBdcst Ad 2: ClaimRoot(tent) NOT 02:19:23.910338 DLoad: ^.idl_timeout.c-doTimeout DBG 02:19:23.911135 DLoad: Timeout XID080027F8 hier=ClaimRoot(tent) NOT 02:19:23.911966 DLoad: ^.idl_protocol.c-sendBroadcastOffer INF 02:19:23.912719 DLoad: XID080027F8 TxBdcst Ad 3: ClaimRoot(tent)INF 02:19:34.410208 DLoad: XID080027F8 Root sending TFTP XfrCmd on ROOT_WAITING TO NOT 02:19:24.160548 DLoad: ^.idl_timeout.c-doTimeout DBG 02:19:24.161318 DLoad: Timeout XID080027F8 hier=ClaimRoot(tent) NOT 02:19:24.162076 DLoad: ^.idl_protocol.c-sendBroadcastOffer INF 02:19:24.162828 DLoad: XID080027F8 TxBdcst Ad 4: ClaimRoot(tent) NOT 02:19:24.410188 DLoad: ^.idl_timeout.c-doTimeout DBG 02:19:24.411262 DLoad: Timeout XID080027F8 hier=ClaimRoot(tent)"
Gibt mehrere Zeitüberschreitungen an, wenn keine Antwort eingeht:
"NOT 02:19:24.412095 DLoad: UT:Confirmed root bumping strength"
Das Telefon wird zum Root, da es keine eingehenden Handshaking-Pakete von den Peers erhalten hat:
NOT 02:19:24.412806 DLoad: @@@HROOT:XID080027F8 H=36685558 m=CP-7961G ROOT=10.106.117.68 /dnld/SCCP41.9-4-2SR2-2S.loads
Unterscheiden zwischen beiden:
Wenn Sie PFS von der Seite "Phone Configuration" (Telefonkonfiguration) aktivieren, besteht kein erheblicher Unterschied zwischen PFS und der herkömmlichen Aktualisierungsmethode. Während der Aktualisierung können jedoch einige Unterschiede auf den Telefonbildschirmen angezeigt werden.
Traditionelle Upgrade-Methode |
PFS |
Alle Telefone zeigen während des Vorgangs den gleichen Bildschirm an. Wenn es z. B. eine Komponente gibt, die auf einem Telefon heruntergeladen wird, zeigen andere ebenfalls dasselbe an. |
Einige Telefone zeigen hier ein anderes Verhalten. Grundsätzlich kann der Status der Komponente x als 100 % angezeigt werden, wobei andere noch auf Komponente x aktualisieren und die KBs anzeigen, die für x heruntergeladen werden. |
Das Feld ist leer für ein herkömmliches Upgrade, wie im Bild gezeigt.
|
Sie sehen das PFS-Symbol in der oberen rechten Ecke des Bildschirms der Telefone zum Zeitpunkt des Upgrades, wie im Bild zu sehen ist.
|
Telefon 1:
|
Telefon 1:
|
Telefon 2:
|
Telefon 2:
|
Telefon 3:
|
Telefon 3:
|
Telefon 4:
|
Telefon 4:
|
Zu beachten:
Für diese Konfiguration ist derzeit kein Überprüfungsverfahren verfügbar.
Für diese Konfiguration sind derzeit keine spezifischen Informationen zur Fehlerbehebung verfügbar.