O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve o recurso PFS (Peer Firmware Sharing) do telefone IP que permite que os telefones IP localizados em locais remotos compartilhem arquivos de firmware entre eles, ao contrário do método tradicional de atualização de firmware do telefone IP que exige que o servidor TFTP (Trivia File Transfer Protocol) envie arquivos de firmware para cada telefone.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
No processo tradicional de atualização de firmware, o servidor TFTP deve se comunicar individualmente com cada telefone e enviar os arquivos de atualização para eles simultaneamente. No entanto, considere um cenário em que 1.000 telefones estejam localizados em um local remoto e o servidor TFTP na matriz esteja a aproximadamente 15.000 kms de distância. Nesse caso, os telefones são conectados ao servidor através da rede remota (WAN) e em uma quantidade enorme. Portanto, a atualização do firmware para esses telefones leva um tempo considerável.
O PFS permite que os telefones IP localizados em locais remotos compartilhem os arquivos de firmware entre eles, o que economiza largura de banda quando o processo de atualização ocorre. Esse recurso usa o Cisco Peer to Peer Distribution Protocol, que é um protocolo proprietário da Cisco usado para formar uma hierarquia de dispositivos ponto a ponto. O Cisco Peer to Peer Distribution Protocol também é usado para copiar o firmware ou outros arquivos de dispositivos pares para os dispositivos vizinhos.
O PFS está incluído nas versões 8.3(1) (e superiores) do firmware do telefone que é fornecido como parte da versão do CUCM 6.0. Ele será aplicável a telefones IP de 3ª geração da Cisco que incluem:
Note: O PFS não se aplica aos telefones 7960 ou 7940 de segunda geração nem aos telefones OEM como os telefones de vídeo Tandberg.
Aqui estão algumas das principais vantagens do PFS em relação ao método de atualização tradicional:
Figura 1. Hierarquia de distribuição do compartilhamento de firmware de mesmo nível
Figura 2. Diferença hierárquica entre o método de atualização tradicional e o PFS
Figura 2 (a). Atualização tradicional de firmware
Figura 2 (b). PFS
Somente o campo PFS precisa ter o valor ativado em qualquer um deles em ordem decrescente de precedência, como mostrado na imagem:
1. Página Configuração do telefone de cada dispositivo remoto.
2. Perfil de telefone comum.
3. Configuração do telefone da empresa.
Este é um trecho dos registros do console tirado do telefone raiz, para confirmar se o PFS funciona aqui:
"DBG 02:19:22.634167 DLoad: +++ fd=7 Listening on peer TCP port 4051"
Indica que o telefone inicia o processo de peer to peer e está pronto para ouvir os pacotes de handshake para configurar uma estrutura Peer to Peer antes de compartilhar o firmware:
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"
O telefone envia uma mensagem de oferta de broadcast para todos os peers, quando se torna a raiz:
"NF 02:19:23.162700 DLoad: XID080027F8 TxBdcst ClaimRoot(tent): map=ff9d7cb9 strength=31d4d43d "
Indica que o telefone começou a reclamar na sub-rede que é a raiz do compartilhamento ponto a ponto:
"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)"
Indica vários tempos limite quando não recebe nenhuma resposta:
"NOT 02:19:24.412095 DLoad: UT:Confirmed root bumping strength"
O telefone torna-se a raiz, pois não recebeu nenhum pacote de handshake dos peers:
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
Marque uma diferença entre ambos:
Quando você ativa o PFS na página Configuração do telefone, não há diferença considerável entre o PFS e o método tradicional de atualização. No entanto, enquanto a atualização está em andamento, algumas diferenças podem ser marcadas nas telas do telefone.
Método de atualização tradicional |
PFS |
Todos os telefones mostram a mesma tela durante todo o processo. Por exemplo, se houver um componente baixado em um telefone, outros também mostrarão o mesmo. |
Alguns dos telefones mostram um comportamento diferente aqui. Basicamente, quem for o(s) pai(es) em um momento, pode mostrar o status do componente x como 100%, enquanto outros ainda atualizam para o componente x e mostrar os KBs baixados para x. |
A caixa está em branco para uma atualização tradicional, como mostrado na imagem.
|
Você pode ver o ícone PFS no canto superior direito da tela dos telefones no momento da atualização, como visto na imagem.
|
Telefone 1:
|
Telefone 1:
|
Telefone 2:
|
Telefone 2:
|
Telefone 3:
|
Telefone 3:
|
Telefone 4:
|
Telefone 4:
|
Pontos a lembrar:
No momento, não há procedimento de verificação disponível para esta configuração.
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.