Introdução
Este documento descreve o firmware do par que compartilha da característica (PFS) do telefone IP que permite os Telefones IP situados em locais remotos a fim compartilhar de arquivos de firmware entre eles, ao contrário do método tradicional da upgrade de firmware do telefone IP que exige o server do protocolo de transferência de arquivo da trivialidade (TFTP) enviar arquivos de firmware a cada telefone.
Pré-requisitos
Requisitos
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Cisco unificou o gerente de uma comunicação (CUCM)
- Processo da upgrade de firmware do telefone IP
As informações neste documento são baseadas nestas versões de software e hardware:
- CUCM 10.5.2.10000-5.
- Cisco unificou o telefone IP 7961 e 7961G.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Informações de Apoio
No processo tradicional da upgrade de firmware, o servidor TFTP é suposto para comunicar-se individualmente com cada telefone, e envia-lhes os arquivos da elevação simultaneamente. Contudo, considere um cenário onde que 1000 telefones são ficados situados em um local remoto e o servidor TFTP nas matrizes é aproximadamente 15000 kms ausentes. Neste caso, os telefones são conectados ao server sobre o Wide Area Network (WAN), e em uma quantidade enorme. Assim, a upgrade de firmware para estes telefones toma uma quantidade de tempo considerável.
O PFS permite os Telefones IP situados em locais remotos para compartilhar dos arquivos de firmware entre eles, que salvar a largura de banda quando o processo de upgrade ocorre. Esta característica usa o par de Cisco para espreitar o protocolo de distribuição que é um protocolo de proprietário de Cisco usado para formar um par para espreitar hierarquia dos dispositivos. Cisco espreita para espreitar protocolo de distribuição é usado igualmente para copiar o firmware ou os outros arquivos dos dispositivos de peer aos dispositivos vizinhos.
O PFS é incluído nas versões de firmware do telefone 8.3(1) (e acima) que envia como parte da liberação CUCM 6.0. Será aplicável aos?ns Telefones IP Gen Cisco que inclui:
- 7906
- 7911
- 7931
- 7941 7961 (atuação e NON-atuação)
- 7970 7971
- Modelos do telefone Gen do futuro os?ns serão apoiados também.
Nota: O PFS é nem aplicável aos òs telefones da geração 7960 ou 7940 nem aos telefones OEM como os telefones de vídeo de Tandberg.
Estão aqui algumas das vantagens chaves do PFS sobre o método de upgrade tradicional:
- Congestão dos limites no link entre o servidor TFTP centralizado e os telefones do IP remoto.
- Ajudas no caso das encenações da largura de banda baixa.
- Mais o número de Telefones IP, melhor é desempenho comparado ao método tradicional da upgrade de firmware.
Trabalho
- O campo PFS precisa de ser permitido para que este trabalhe.
- O PFS trabalha em uma hierarquia, onde um telefone se transforme o pai, e na outro, seu telefone da criança. Quando a elevação é iniciada, o TFTP envia os arquivos de firmware (um por um) ao telefone do pai. Os outros telefones esperam até que a transferência do componente estiver completa no pai. Então, uma vez que um componente é recebido completamente pelo pai, passa-o sobre a seus telefones da criança através de uma conexão de TCP. Isto trabalha na maneira de uma árvore binária, onde um telefone possa ter telefones da criança do máximo 2 segundo as indicações da imagem:
Figura 1. firmware do par que compartilha da hierarquia da distribuição

Figura 2. diferença hierárquica entre o método de upgrade tradicional e o PFS

Figura 2 (a). Upgrade de firmware tradicional

Figura 2 (b). PFS
Configurar o PFS
Somente o campo PFS precisa de ter o valor permitido em qualquer uma destes por ordem decrescente da precedência segundo as indicações da imagem:
1. Página da configuração telefônica de cada dispositivo remoto.
2. Perfil comum do telefone.
3. Configuração telefônica da empresa.

Este é um trecho dos logs do console tomados do telefone da raiz, a fim confirmar que o PFS trabalha aqui:
"DBG 02:19:22.634167 DLoad: +++ fd=7 Listening on peer TCP port 4051"
Indica que o telefone começa o processo de par espreitar e está pronto para escutar os pacotes do aperto de mão para setup um par para espreitar estrutura antes que compartilhe do 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 da oferta da transmissão a todos os pares, quando se transforma a raiz:
"NF 02:19:23.162700 DLoad: XID080027F8 TxBdcst ClaimRoot(tent): map=ff9d7cb9
strength=31d4d43d "
Indica o telefone ligado reivindicar-se na sub-rede que é a raiz do par a espreitar compartilhando:
"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 os intervalos múltiplos em que não obtém nenhuma respostas:
"NOT 02:19:24.412095 DLoad: UT:Confirmed root bumping strength"
O telefone transforma-se a raiz desde que não obteve nenhuns pacotes recebidos de aperto de mão dos pares:
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ê permite o PFS da página da configuração telefônica, não há nenhuma diferença considerável entre o PFS e o método tradicional da elevação. Contudo, quando a elevação estiver no processo, algumas diferenças podem ser marcadas das telas do telefone.
Método de upgrade tradicional
|
PFS
|
Todos os telefones mostram a mesma tela durante todo o processo. Por exemplo, se há um componente que está transferido em um telefone, outro igualmente mostra o mesmos. |
Alguns dos telefones mostram um comportamento diferente aqui. Basicamente, quem quer que is/are o pai em um instante, pôde mostrar o estado do componente x como 100%, visto que outro ainda promove ao componente x, e, mostre o KBs que é transferido para o X. |
A caixa está vazia para uma elevação tradicional segundo as indicações da imagem.  |
Você pode ver o ícone PFS no canto superior direito da tela dos telefones na altura da elevação como visto na imagem.  |
Telefone 1:  |
Telefone 1:  |
Telefone 2:  |
Telefone 2:  |
Telefone 3:  |
Telefone 3:  |
Telefone 4:  |
Telefone 4:  |
Pontos a recordar:
- O PFS trabalha em um arquivo pela base do arquivo. Um telefone pôde transformar-se pai para uma arquivo ou criança para outra, na altura da mesma elevação.
- O PFS é específico do telefone-modelo; os tipos de telefone diferentes formarão hierarquias múltiplas.
- O PFS pode somente trabalhar com os telefones na mesma sub-rede.
- Mais o número de dispositivos, melhor é seu desempenho.
- Dá melhores resultados quando os telefones são restaurados no volume.
- Todo o tráfego de broadcast de UDP e da criança TCP conexões do telefone a telefonar ocorrem na porta 4051.
- A fim configurar o firmware do par que compartilha para telefones múltiplos imediatamente:
- Para o Gerenciador de Comunicações 5.0 de Cisco e mais atrasado, permita ajustes do firmware do par no indicador do template de telefone da ferramenta de administração de grande escala.
- Para o gerente das comunicações unificadas de Cisco 4.1(3), 4.2(3) e 4.3(1), transferem um script AXL:
Erros
- CSCtg96408 - o telefone Terceiro-gen (7911/41, etc.) não carreg depois que elevação PFS.
- CSCso40251 - Não do “firmware par que compartilha” do campo para 7975/7965 em CUCM ES 5.1.2.3127-1.
- CSCsh98792 - Os telefones da atualização Admin do volume CM 5.x/6.0 não ajustam params do específico do produto.
- CSCud66570 - firmware de 7931 pares que compartilha desabilitado sempre.
- CSCui49910 - [Pegatron] “nenhum firmware do par do "" que compartilha do "" na instalação de rede do página da web”.
- CSCus67416 - Permita do “o firmware par que compartilha”, o telefone B ainda vão à transferência fw dos server.
- CSCtb49726 - A opção do compartilhamento de arquivo do par falta no conf específico do produto em 7942/62.
- CSCsh20977 - Adicionando o firmware específico Sharin GN do par das características dos novos produtos no mundo inteiro.
Verificar
No momento, não há procedimento de verificação disponível para esta configuração.
Troubleshooting
Atualmente, não existem informações disponíveis específicas sobre Troubleshooting para esta configuração.
Informações Relacionadas