Protocolo Network Time Protocol: White Paper de práticas recomendadas

Introdução

As redes baseadas em Internet Protocol (IP) estão evoluindo rapidamente do modelo tradicional de entrega com melhor esforço para um modelo onde o desempenho e a confiança precisam ser quantificados e, em muitos casos, garantidos por contratos de nível de serviço (SLA). A necessidade de um maior insight nas características da rede levaram a esforços de pesquisas significativos visando a definição de métricas e recursos de medição para caracterizar o comportamento da rede. A base de muitas metodologias de métrica é a medição do tempo.

Informações de Apoio

A sincronização de tempo de rede, ao grau exigido para a análise de desempenho moderna, é um exercício essencial. Segundo os modelos de negócio, e os serviços que estão sendo fornecidos, a caracterização do desempenho da rede pode ser considerada um diferenciador importante do serviço competitivo. Nesses casos, as grandes despesas podem ser sistemas de gerenciamento de rede de distribuição incorridos e recursos de engenharia da direção para a análise dos dados de desempenho recolhidos. Contudo, se a atenção apropriada não é dada ao princípio frequentemente-negligenciado de sincronização de tempo, aqueles esforços podem ser tornados inúteis.

Este original descreve uma definição de processo hipotética para funções de gerenciamento de rede de condução para o Network Time Protocol (NTP). Pretende-se que este procedimento hipotético esteja usado como um exemplo informativo e personalizado por uma organização para ajudar em encontrar objetivos internos.

A informação fornecida por este papel é apresentada em diversas seções principal, que são descritas abaixo.

A seção da terminologia fornece definições gerais dos termos a respeito da sincronização de tempo.

A seção de visão geral fornece a informações de fundo no hardware do elemento de rede relativo ao tempo de sistema, a uma visão geral tecnológica do NTP, e às características do design chaves para a arquitetura de NTP.

A seção do exemplo de desenvolvimento de NTP fornece exemplos de distribuição NTP as configurações de amostra para WAN, o terreno alto do estrato, e as redes de distribuição de tempo de campus de estrato baixo.

A seção de definições de processo fornece uma vista geral das definições de processo usadas para realizar o gerenciamento de NTP. Os detalhes do processo são descritos em termos de metas, indicadores de desempenho, entradas, saídas e tarefas individuais.

A seção Task Definitions (Definições de tarefas) fornece definições detalhadas sobre as tarefas do processo. Cada tarefa é descrita em termos dos objetivos, das entradas de tarefa, das saídas da tarefa, dos recursos exigidos para realizar a tarefa, e das habilidades de trabalho necessárias para um implementador de tarefas.

A seção de identificação de dados descreve a identificação de dados para o NTP. A identificação de dados considera a fonte da informação. Por exemplo, a informação pode ser contida no Management Information Base do Simple Network Management Protocol (SNMP) (MIB), em arquivos de log gerado do Syslog, ou pelas estruturas de dados internas que podem somente ser alcançadas pelo comando line interface(cli).

A seção de levantamento de dados descreve a coleção dos dados NTP. A coleta dos dados está intimamente ligada à localização dos dados. Por exemplo, dados de SNMP MIB são coletados por vários mecanismos, como armadilhas, alarmes e eventos de Remote Monitoring (RMON) ou eleição. Os dados mantidos por estruturas de dados internas são recolhidos por scripts automáticos ou por um usuário que registra manualmente no sistema para emitir o comando CLI e que grava a saída.

A seção da apresentação de dados fornece exemplos do formato de relatório de como os dados podem ser apresentados.

Terminology

• Precisão — A proximidade do valor absoluto do pulso de disparo ao offset de zero.

• Exato — Quando o offset de um pulso de disparo for zero em um momento específico a tempo.

• Tração — A medida na variação do enviesamento, ou a segunda derivação do offset do pulso de disparo no que diz respeito ao tempo.

• Resolução conjunta — Ao comparar pulsos de disparo, esta é a soma das definições do C1 e do C2. A resolução conjunta indica então um limite inferior conservador na precisão de quando os intervalos computados subtraindo os marcadores temporais gerados por um pulso de disparo daqueles gerados pelo outro.

• Nó — Refere uma instanciação do protocolo NTP em um processador local. Um nó pode igualmente ser referido como um dispositivo.

• Offset — A diferença entre o tempo relatou em um pulso de disparo e o tempo verdadeiro como definido no tempo universal coordenado (UTC). Se o pulso de disparo relata que um momento Tc e o tempo verdadeiro são Tt, a seguir o offset do pulso de disparo é Tc - Tt.

• Par — Refere uma instanciação do protocolo NTP em um processador remoto conectado por um caminho de rede do nó local.

• Deslocamento relativo — A noção do tempo verdadeiro é substituída antes que como relatado pelo pulso de disparo C1, quando comparando como dois pulsos de disparo, C1 e C2, comparam. Por exemplo, o offset C1 relativo a do C2 do pulso de disparo em um momento específico é Tc2 - Tc1, a diferença no tempo instantânea relatada pelo C2 e C1.

• Definição — A unidade a menor por que uma horas é atualizada. A definição é definida em termos dos segundos. Contudo, a definição realiza-se relativo ao período relatado do pulso de disparo e para não retificar o tempo. Por exemplo, uma definição dos milissegundos 10 significa que o pulso de disparo atualiza sua noção do tempo em 0.01 segundos incrementos e não significa que esta é a quantidade de tempo verdadeira entre atualizações.

  Nota: Os pulsos de disparo podem ter muito resoluções justa e ainda ser imprecisos.

• Enviesamento — A diferença de frequência de um pulso de disparo, ou o primeiro derivado de seu offset no que diz respeito ao tempo.

• Sincronizar — Quando dois pulsos de disparo forem exatos no que diz respeito a um outro (o deslocamento relativo é zero), estão sincronizados. Os pulsos de disparo podem ser sincronizados e ainda impreciso em termos de como bom dizem o tempo verdadeiro.

Overview

Visão geral do dispositivo

O coração do serviço de tempo é o relógio de sistema. O relógio de sistema executa do momento os começos do sistema e mantém-se a par da data atual e hora. O relógio de sistema pode ser ajustado de um número de fontes e, por sua vez, pode ser usado para distribuir as horas atual através dos vários mecanismos a outros sistemas. Algum Roteadores contém um sistema de calendário movido à bateria que siga a data e hora através dos reinícios do sistema e das interrupções de energia. Este sistema de calendário está usado sempre para inicializar o relógio de sistema quando o sistema é reiniciado. Pode igualmente ser considerado como uma fonte competente de tempo e ser redistribuído com o NTP se nenhuma outra fonte está disponível. Além disso, se o NTP está sendo executado, o calendário pode periodicamente ser atualizado do NTP, compensando a tração inerente no tempo do calendário. Quando um roteador com um calendário do sistema é inicializado, o relógio de sistema é ajustado baseado no tempo em seu calendário movido à bateria interno. Em modelos sem um calendário, o relógio de sistema é ajustado a uma constante de horário pré-determinado. O relógio de sistema pode ser ajustado das fontes alistadas abaixo.

• NTP

• Protocolo de tempo de rede simples (SNTP)

• Serviço de tempo do serviço de rede integrada virtual (VINES)

• Configuração manual

Determinado apoio baixo da gama SNTP dos dispositivos Cisco somente. O SNTP é uma versão simplificada, somente cliente do NTP. O SNTP pode somente receber o tempo dos servidores de NTP e não pode ser usado para proporcionar o Time Services a outros sistemas. O SNTP fornece tipicamente o tempo dentro de 100 milissegundos do tempo precisa. Além, o SNTP não autentica o tráfego, embora você possa configurar listas de acesso extendida para fornecer alguma proteção. Um cliente SNTP é mais vulnerável aos server portando-se mal do que um cliente de NTP e deve somente ser usado nas situações onde a autenticação forte não é exigida.

O relógio de sistema fornece o tempo aos serviços alistados abaixo.

• NTP

• Serviço de tempo VINES

• Comandos show do usuário

• Registro e mensagens de debugging

O relógio de sistema mantém-se a par do tempo baseado internamente no UTC, igualmente conhecido como o horário de Greenwich (GMT). Você pode configurar a informação sobre o fuso horário local e o tempo do horário de verão de modo que o tempo seja indicado corretamente relativo ao fuso horário local. O relógio de sistema mantém-se a par se o tempo é competente ou não. Se não é competente, o tempo estará disponível somente para finalidades do indicador e não estará redistribuído.

Visão geral do NTP

O NTP é projetado sincronizar o tempo em uma rede das máquinas. O NTP executa sobre o User Datagram Protocol (UDP), usando a porta 123 como a fonte e o destino, que executa por sua vez sobre o IP. O RFC 1305 da versão 3 NTP é usado para sincronizar a manutenção de horas entre um grupo de Times Server e de clientes distribuídos. Um grupo de Nós em uma rede é identificado e configurado com NTP e os Nós forme uma sub-rede de sincronização, referida às vezes como uma rede de folha de prova. Quando os mestres múltiplos (servidores primários) puderem existir, não há nenhuma exigência para um protocolo de eleição.

Uma rede NTP obtém geralmente seu tempo de uma fonte de tempo autoritária, tal como um relógio de rádio ou um relógio atômico anexado a um Time Server. O NTP distribui então esta vez através da rede. Um cliente de NTP faz uma transação com seu server sobre seu intervalo de polling (64 a 1024 segundos) que muda dinamicamente ao longo do tempo segundo as condições de rede entre o servidor de NTP e o cliente. A outra situação ocorre quando o roteador se comunica a um servidor de NTP ruim (por exemplo, servidor de NTP com grande dispersão); o roteador igualmente aumenta o intervalo de votação. Não mais de uma transação NTP pelo minuto é precisada de sincronizar duas máquinas. Não é possível ajustar o intervalo de votação NTP em um roteador.

O NTP usa o conceito de um estrato para descrever quantos lúpulos NTP afastado uma máquina é de uma fonte de tempo autoritária. Por exemplo, um Time Server do estrato 1 tem um rádio ou um relógio atômico anexado diretamente a ele. Envia então seu tempo a um Time Server do estrato 2 com o NTP, e assim por diante. Uma máquina que executa o NTP escolhe automaticamente a máquina com o mais baixo número de estrato que é configurada para comunicar com a utilização do NTP como seu origem de tempo. Esta estratégia constrói eficazmente uma árvore selforganizing de oradores NTP. O NTP executa bem sobre os comprimentos de trajeto NON-determinísticas de redes comutáveis por blocos, porque faz avaliações robustas das seguintes três variáveis chaves no relacionamento entre um cliente e um Time Server.

• Retardo de rede

• Dispersão de intercâmbios de pacotes do tempo — Uma medida do erro de relógio máximo entre os dois anfitriões.

• Pulso de disparo deslocado — A correção aplicou-se ao pulso de disparo de um cliente para sincronizá-lo.

A sincronização de relógio nas redes de área ampla interurbanas excedentes niveladas do milissegundo 10 (WAN) (2000 quilômetros), e no 1 milissegundo em nível para as redes de área local (LAN), é conseguida rotineiramente.

O NTP evita sincronizar a uma máquina cuja a hora não possa ser exata em duas maneiras. Antes de mais nada, NTP sincronizars nunca a uma máquina que não seja sincronizada. Em segundo lugar, o NTP compara o tempo relatado por diversas máquinas, e não o sincronizará a uma máquina cuja a hora seja significativamente diferente do que a outro, mesmo se seu estrato é mais baixo.

As comunicações entre as máquinas que executam NTP (associações) geralmente são configuradas estaticamente. Cada máquina é dada o IP address de todas as máquinas com que deve formar associações. A cronometragem precisa é tornada possível trocando mensagens de NTP entre cada par de máquinas com uma associação. Contudo, em um ambiente de LAN, o NTP pode ser configurado para usar pelo contrário mensagens de transmissão IP. Esta alternativa reduz a complexidade de configuração porque cada máquina pode ser configurada para enviar ou receber mensagens de transmissão. Contudo, a exatidão de cronometragem é reduzida marginalmente porque a informação de fluxo é de sentido único somente.

O tempo mantido em uma máquina é uns recursos críticos e é recomenda fortemente que você usa os recursos de segurança do NTP para evitar o ajuste acidental ou malicioso das horas incorreta. Os dois recursos de segurança disponíveis são um esquema de restrição lista-baseado acesso e um mecanismo de autenticação criptografada.

A aplicação de Cisco do NTP apoia o serviço do estrato 1 em determinados software release do Cisco IOS. Se uma liberação apoia o comando ntp refclock, é possível conectar um rádio ou um relógio atômico. Determinadas liberações do Cisco IOS apoiam o jogo da sincronização da paliçada NTP de Trimble (Cisco 7200 Series Router somente) ou o dispositivo do Global Positioning System das soluções de telecom (GPS). Se os usos da rede os servidores de tempo público no Internet e na rede são isolados do Internet, a aplicação de Cisco do NTP permite que uma máquina esteja configurada de modo que atue como se está sincronizada com o NTP, quando de fato determinou o tempo usando outros meios. Outras máquinas sincronizam então a essa máquina com o NTP.

Critérios de padrão NTP

Cada cliente na sub-rede de sincronização, que pode igualmente ser um server para uns clientes mais altos do estrato, escolhe um dos server disponíveis sincronizar a. Isto está geralmente entre dos mais baixos servidores stratum que tem o acesso a. Contudo, esta não é sempre uma configuração ótima, porque o NTP igualmente se opera sob os locais que o tempo de cada server deve ser visto com uma certa quantidade de desconfiança. O NTP prefere ter o acesso a diversas fontes do tempo de estrato inferior (pelo menos três) desde que pode então aplicar um algoritmo do acordo para detectar a demência da parte de qualquer um destes. Normalmente, quando todos os server estão no acordo, o NTP escolhe o melhor server em termos do mais baixo estrato, o mais próximo (em termos do retardo de rede), e da precisão reivindicada. A implicação é que, quando uma dever apontar fornecer cada cliente três ou mais fontes de tempo de estrato inferior, diversa destes somente estará proporcionando o serviço de backup e pode ser de pouca qualidade em termos do retardo de rede e do estrato. Por exemplo, um par do mesmo-estrato que receba o tempo das fontes do estrato mais baixo o servidor local não alcança diretamente, pode igualmente proporcionar o bom serviço de backup.

O NTP prefere geralmente server do estrato mais baixo a uns servidores stratum mais altos a menos que o tempo do server do estrato mais baixo for significativamente diferente. O algoritmo pode detectar quando um origem de tempo é provável ser extremamente impreciso, ou insano, e impedir nesses casos a sincronização, mesmo se o pulso de disparo impreciso está a nível do estrato mais baixo. E nunca sincronizará um dispositivo a um outro server que não seja sincronizado.

A fim declarar se o server é seguro, precisa de passar a muitos a verificação de sanidade, como:

• As aplicações devem incluir os intervalos da sanidade que impedem transmissões da armadilha se o programa de monitorização não renova esta informação após um intervalo longo.

• As verificações de sanidade adicionais são incluídas para a autenticação, limites da escala, e para evitar o uso de dados muito velhos.

• As verificações foram adicionadas para advertir que o oscilador tem ido demasiado por muito tempo sem atualização de uma fonte de referência.

• As variáveis peer.valid e sys.hold estiveram adicionadas para evitar instabilidades quando a fonte de referência muda rapidamente devido aos grandes atrasos dispersivos sob circunstâncias do congestionamento de rede severo. Os bit peer.config, peer.authenable, e peer.authentic foram adicionados para controlar recursos especiais e simplificar a configuração.

Se pelo menos um daqueles verifica a falha, o roteador declara-a insana.

Modos de associação

As seguintes seções descrevem os modos de associação usados por servidores de NTP para associar um com o otro.

• Cliente/server

• Ativo simétrico/voz passiva

• Broadcast

Modo cliente/servidor

Os clientes e servidor dependentes operam-se normalmente no modo cliente/servidor, em que um servidor cliente ou dependente pode ser sincronizado a um membro do grupo, mas nenhum membro do grupo pode sincronizar ao servidor cliente ou dependente. Isto fornece a proteção contra maus funcionamentos ou ataques contra protocolo.

O modo cliente/servidor é a configuração a mais comum do Internet. Opera-se no paradigma clássico do Remote-procedure-call (RPC) com servidores stateless. Neste modo, um cliente envia um pedido ao server e espera uma resposta em alguma hora futura. Em alguns contextos, isto seria descrito como uma operação da votação, nisso o cliente vota o tempo e os dados de autenticação do server. Um cliente é configurado no modo de cliente usando o comando server e especificando o nome ou o endereço do Domain Name Server (DNS). O server não exige nenhuma configuração anterior.

Em um modelo cliente/servidor comum, um cliente envia um mensagem de NTP a uns ou vários server e processa as respostas como recebidas. O server intercambia endereços e portas, overwrites determinados campos na mensagem, volta a calcular a soma de verificação, e retorna a mensagem imediatamente. A informação incluída no mensagem de NTP permite que o cliente determine o tempo de servidor no que diz respeito ao horário local e ajuste o relógio local em conformidade. Além, a mensagem inclui a informação para calcular a precisão e a confiança previstas da manutenção de horas, assim como para selecionar o melhor server.

Os server que fornecem a sincronização a uma população importante dos clientes operam-se normalmente como um grupo de três ou mais mutuamente servidores redundantes, cada funcionamento com três ou mais server do estrato 1 ou do estrato 2 nos modos cliente/servidor, assim como todos membros restantes do grupo nos modos simétricos. Isto fornece a proteção contra maus funcionamentos em qual ou mais server não operam nem não fornecem horas incorreta. Os algoritmos NTP forem projetados para resistir ataques quando alguma fração dos origens de sincronização configurados fornecem acidentalmente ou propositadamente horas incorreta. Nesses casos, um procedimento de votação especial é usado para identificar fontes especulativos e para rejeitar seus dados. No interesse da confiança, os anfitriões selecionados podem ser equipados com os relógios externos e ser usados para o backup em caso da falha do preliminar e/ou os servidores secundários, ou trajetos de comunicação entre ele.

Configurar uma associação no modo de cliente, indicado geralmente por uma declaração do server no arquivo de configuração, indica que um deseja obter o tempo do servidor remoto, mas que um não é disposto fornecer o tempo ao servidor remoto.

Modo ativo/passivo simétrico

O modo ativo/passivo simétrico é pretendido para as configurações onde um grupo de baixos pares do estrato se opera como backup mútuos para se. Cada par opera-se com uns ou vários origens da referência principais, tais como um relógio de rádio, ou um subconjunto de servidores secundários seguros. Se um dos pares perder todas as fontes de referência ou cessar simplesmente a operação, os outros pares reconfiguram automaticamente de modo que os valores do tempo possam fluir dos pares de sobrevivência a todos os outro na pequena associação. Em alguns contextos isto é descrito como uma operação push pull, que o par puxa ou empurra o tempo e os valores segundo a configuração específica.

Configurar uma associação no modo ativo simétrico, indicado geralmente por uma declaração do par no arquivo de configuração, indica ao servidor remoto que um deseja obter o tempo do servidor remoto e que um igualmente está querendo fornecer caso necessário o tempo ao servidor remoto. Este modo é apropriado nas configurações que envolvem um número de Times Server redundantes interconectados através dos caminhos de rede diversa, que é presentemente a caixa para a maioria de server do estrato 1 e do estrato 2 no Internet hoje.

Os modos simétricos são os mais usados frequentemente entre dois ou mais server que operam-se como um grupo mutuamente redundante. Nestes modos, os server nos membros do grupo arranjam os trajetos da sincronização para o desempenho máximo, segundo o atraso de sincronismo de rede e o retardo de propagação. Se uns ou vários dos membros do grupo falham, os membros restantes reconfiguram automaticamente como necessário.

Um par é configurado no modo ativo simétrico usando o comando peer e especificando o nome DNS ou o endereço do outro par. O outro par é configurado igualmente no modo ativo simétrico desta maneira.

Nota: Se o outro par não é configurado especificamente desta maneira, uma associação passiva simétrica está ativada em cima da chegada de um mensagem ativa simétrico. Desde que um intruso pode encarnar um peer ativo simétrico e injetar valores de tempo falso, o modo simétrico deve sempre ser autenticado.

Transmissão e/ou Modo multicast

Onde as exigências na precisão e na confiança são modestas, os clientes podem ser configurados para usar modos da transmissão e/ou do Multicast. Normalmente, estes modos não são utilizados por server com clientes dependentes. A vantagem é que os clientes não precisam de ser configurados para um server específico, permitindo que todos os clientes de funcionamento usem o arquivo de mesma configuração. O modo de transmissão exige um servidor de transmissão na mesma sub-rede. Desde que os mensagens de transmissão não são propagados pelo Roteadores, simplesmente os servidores de transmissão na mesma sub-rede são usados.

O modo de transmissão é pretendido para as configurações que envolvem um ou algum server e uma população potencialmente grande do cliente. Um servidor de transmissão é configurado usando o comando broadcast e um endereço de sub-rede local. Um cliente de transmissão é configurado usando o comando broadcastclient, permitindo que o cliente de transmissão responda aos mensagens de transmissão recebidos em toda a relação. Desde que um intruso pode encarnar um servidor de transmissão e injetar valores de tempo falso, este modo deve sempre ser autenticado.

Ajustando o segundo de pulo NTP

Você pode usar o pulo NTP {adicionar | comando da supressão} a fim introduzir um segundo de pulo. Há umas opções para adicionar e suprimir de segundos de pulo. Há duas limitações para que esta ocorra:

• O pulso de disparo deve estar no estado de sincronização.

• O comando está aceitado somente dentro do mês antes que o pulo esteja acontecer. Não ajustará o pulo se as horas atual se realizam antes de 1 mês da ocorrência do pulo.

Depois que você o ajusta, o segundo de pulo obtém adicionado ou suprimido ao último segundo como mostrado aqui:

NTP leap second added :
Show clock given continuously
vl-7500-6#show clock
23:59:58.123 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:58.619 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:59.123 UTC Sun Dec 31 2006
vl-7500-6#show clock
23:59:59.627 UTC Sun Dec 31 2006
<< 59th second occuring twice
vl-7500-6#show clock
23:59:59.131 UTC Sun Dec 31 2006    
vl-7500-6#show clock
23:59:59.627 UTC Sun Dec 31 2006
vl-7500-6#show clock
00:00:00.127 UTC Mon Jan 1 2007
vl-7500-6#show clock
00:00:00.623 UTC Mon Jan 1 2007

Arquitetura de NTP

As seguintes três estruturas estão disponíveis para a arquitetura de NTP.

• Estrutura de flat peer

• Estrutura hierárquica

• Estrutura de início

Em uma estrutura de flat peer, todo o Roteadores espreita um com o otro, com alguns geograficamente roteadores separados configurados para apontar aos sistemas externos. A convergência do tempo torna-se mais por muito tempo com cada membro novo da malha NTP.

Em uma estrutura hierárquica, a hierarquia de roteamento é copiada para a hierarquia NTP. Os roteadores centrais têm um relacionamento cliente/servidor com origens de tempo externo, os servidores de horário interno têm um relacionamento cliente/servidor com os roteadores centrais, o cliente interno (não Times Server) que o Roteadores tem um relacionamento cliente/servidor com os servidores de horário interno, e assim por diante abaixo da árvore. Estes relacionamentos são chamados escalas da hierarquia. Uma estrutura hierárquica é a técnica preferida porque fornece a consistência, a estabilidade, e a escalabilidade.

Uma arquitetura de NTP escalável tem uma estrutura hierárquica como visto no diagrama abaixo.

Em uma estrutura de início, todo o Roteadores tem um relacionamento cliente/servidor com alguns Times Server no núcleo. Os Times Server dedicados são o centro da estrela e são geralmente sistemas de UNIX sincronizados com os origens de tempo externo, ou seu próprio receptor de GPS.

Tecnologia de relógio e servidores de tempo público

A sub-rede do Internet NTP inclui presentemente sobre 50 servidores primários públicos sincronizados diretamente ao UTC pelo rádio, pelo satélite, ou pelo modem. Normalmente, estações de trabalho de cliente e servidores com um número relativamente pequeno de clientes não sincronizam com servidores primários. Aproximadamente 100 servidores secundários públicos são sincronizados aos servidores primários, fornecendo a sincronização a um total além de 100,000 clientes e servidor no Internet. As lista dos Times Server do público NTP são atualizadas frequentemente. Há igualmente numerous private primary e servidores secundários não normalmente disponíveis ao público.

Nota:  O PIX e o ASA não podem ser configurados como um servidor de NTP, mas pode ser configurado como um cliente de NTP.

Em certos casos, onde os serviços do tempo precisa são exigidos altamente na empresa privada, tal como o medidor de sentido único para a Voz sobre medidas IP (VoIP), os projetistas de rede podem escolher distribuir origens de tempo externo privados. O diagrama abaixo mostra um gráfico comparativo da precisão relativa das tecnologias atual.

Até recentemente, o uso dos origens de tempo externo não foi distribuído extensamente nas redes de empreendimento devido aos altos custos de origens de tempo externo da qualidade. Contudo, como as exigências do Qualidade de Serviço (QoS) aumentam e o custo da tecnologia do tempo continua a diminuir, os origens de tempo externo para redes de empreendimento estão transformando-se uma opção viável.

Exemplo de implantações de NTP

Rede de distribuição de tempo WAN

No diagrama abaixo, um sistema autônomo corporativo obtém a informação de tempo de três servidores de tempo público. O corporativo COMO é mostrado como Times Server da área 0 e da área 1. Neste exemplo, a hierarquia NTP segue a hierarquia do Open Shortest Path First (OSPF). Contudo, o OSPF não é uma condição prévia para o NTP. É usado somente como um exemplo ilustrativo. O NTP pode ser distribuído ao longo de outros limites hierárquicos lógicos tais como uma hierarquia do Enhanced Interior Gateway Routing Protocol (EIGRP) ou a hierarquia padrão do núcleo/distribuição/acesso.

O seguinte é a configuração do IOS da Cisco para o dispositivo A0-R1 no diagrama acima.

clock timezone CST -5
clock summer-time CDT recurring


!--- This router has a hardware calendar. !--- To configure a system as an !--- authoritative time source for a network !--- based on its hardware clock (calendar), !--- use the clock calendar-valid global !--- configuration command. Notice later that !--- NTP will be allowed to update the calendar !--- and Cisco IOS will be configured to be an !--- NTP master clock source. !--- Cisco IOS will then obtain its clock from !--- the hardware calendar.


clock calendar-valid


!--- This allows NTP to update the hardware !--- calendar chip.


ntp update-calendar


!--- Configures the Cisco IOS software as an !--- NTP master clock to which peers synchronize !--- themselves when an external NTP source is !--- not available. Cisco IOS will obtain the !--- clock from the hardware calendar based on !--- the previous line. This line will keep the !--- whole network in Sync even if Router1 loses !--- its signal from the Internet. Assume, for !--- this example, that the Internet time servers !--- are stratum 2.


ntp master 3


!--- When the system sends an NTP packet, the !--- source IP address is normally set to the !--- address of the interface through which the !--- NTP packet is sent. !--- Change this to use loopback0.


ntp source Loopback0


!--- Enables NTP authentication.


ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234


!--- Configures the access control groups for !--- the public servers and peers for additional !--- security.


access-list 5 permit <I-TS-1>
access-list 5 permit <I-TS-2>
access-list 5 permit <I-TS-3>
access-list 5 permit <A0-R2>
access-list 5 permit <A0-R3>
access-list 5 deny any


!--- Configures the access control groups for the !--- clients to this node for additional security.


access-list 6 permit <A1-R1>
access-list 6 permit <A1-R2>
access-list 6 permit <A1-R3>
access-list 6 deny any


!--- Restricts the IP addresses for the peers !--- and clients.

 
ntp access-group peer 5
ntp access-group serve-only 6


!--- Fault tolerant configuration polling for 3 NTP !--- public servers, peering with 2 local servers.


ntp server <I-TS-1>
ntp server <I-TS-2>
ntp server <I-TS-3>
ntp peer <A0-R2> 
ntp peer <A0-R3>

Rede de distribuição de tempo de campus de alto estrato

A seção anterior descreveu uma rede de distribuição de tempo MACILENTO. Esta seção move um abaixador na hierarquia para discutir a distribuição de tempo em uma rede de campus de alto estrato.

A diferença principal ao considerar a distribuição de tempo em uma rede de campus de alto estrato é o uso potencial do modo de associação de transmissão. Como descrito mais cedo, o modo de associação de transmissão simplifica as configurações para os LAN, mas reduz a precisão dos cálculos do tempo. Consequentemente, as trocas nos custos de manutenção devem ser consideradas contra a precisão nas medidas de desempenho.

A rede de campus de alto estrato, mostrada no diagrama acima, é tomada do projeto de rede de campus padrão de Cisco e contém três componentes. O campus principal consiste em dois dispositivos da camada 3 etiquetados CB-1 e CB-2. O componente de servidor, situado na seção mais baixa da figura, tem dois 3 Router da camada etiquetados SD-1 e SD-2. Os dispositivos remanescente no bloco do server são dispositivos da camada 2. Na esquerda superior, há um bloqueio de acesso padrão com os dois dispositivos de distribuição da camada 3 etiquetados dl-1 e dl-2. Os dispositivos remanescente são switch de Camada 2. Neste bloco de acesso ao cliente, o tempo é distribuído usando a opção da transmissão. No direito superior, há um outro bloqueio de acesso padrão que use uma configuração da distribuição do cliente/tempo de servidor.

Os dispositivos de backbone de campus são sincronizados aos Times Server da área em um modelo cliente/servidor.

A configuração para dl-1 os dispositivos de distribuição da camada 3 é mostrada abaixo.

!--- In this case, dl-1 will be a broadcast server !--- for the Layer 2 LAN.


internet Ethernet0
ntp broadcast

clock timezone CST -5
clock summer-time CDT recurring


!--- When the system sends an NTP packet, the !--- source IP address is normally set to the !--- address of the interface through which the !--- NTP packet is sent. !--- Change this to use loopback0.


ntp source Loopback0


!--- Enables NTP authentication.


ntp authenticate
ntp authentication-key 1234 md5 104D000A0618 7
ntp trusted-key 1234


!--- Configures the access control groups for !--- the public servers and peers for !--- additional security.


access-list 5 permit <CB-1>
access-list 5 permit <CB-2>
access-list 5 permit <dl-2>
access-list 5 deny any



!--- Restricts the IP addresses for the peers !--- and clients.


ntp access-group peer 5


!--- Fault tolerant configuration polling 2 !--- local time servers and 1 local peer.


ntp server <CB-1>
ntp server <CB-2>
ntp peer <dl-2>

Rede de distribuição de tempo de campus de baixo estrato

No diagrama abaixo, GPS ou uma fonte do tempo de césio são fornecidos no centro de dados central para a rede de campus de estrato baixo. Isto provisions um origem de tempo do estrato 1 na rede privada. Se há GPS múltiplo ou umas fontes do tempo de césio situadas na rede privada, a seguir a distribuição de tempo na rede privada deve ser alterada para aproveitar-se das fontes do tempo disponível.

Geralmente, os mesmos princípios e configurações aplicam-se como com os exemplos anteriores. A diferença principal é neste caso que a raiz da árvore de sincronização é um origem de tempo privado um pouco do que um origem de tempo público do Internet. Isto muda o projeto da rede de distribuição de tempo para aproveitar-se do origem de tempo privado da alta precisão. O origem de tempo privado é distribuído durante todo a rede privada usando os princípios de hierarquia e de modularidade que foram descritos nas seções anterior.

Definições de processo

Uma definição de processo é uma série de ações, atividades e alterações relacionadas executadas por agentes com a intenção de atender a uma finalidade ou de alcançar uma meta.

Controle de processo é o processo de planejar e regular com o objetivo de executar um processo de maneira eficiente.

Graficamente, isto é mostrado no diagrama abaixo.

A saída do processo deve estar de acordo com as normas operacionais definidas por uma organização e tem base nos objetivos comerciais. Se o processo estiver conforme o conjunto de normas, o processo é considerado eficaz porque pode ser repetido, medido, gerenciado e contribui para objetivos comerciais. Se as atividades forem realizadas com um esforço mínimo, o processo também será considerado eficiente.

Proprietário de processo

Os processos englobam diversos limites organizacionais. Portanto, é importante ter um único proprietário de processo que seja responsável pela definição do processo. O proprietário é o ponto focal para determinar e relatar se o processo é efetivo e eficiente. Se o processo não for eficiente, seu proprietário providenciará a modificação. A modificação do processo é regida pelos processos de controle e revisão de alterações.

Objetivos do processo

Metas do processo são estabelecidas para definir a direção e o escopo para a definição do processo. Os objetivos são usados também para definir a métrica a ser usada para medir a eficácia de um processo.

O objetivo deste processo é fornecer os critérios a ser documentados durante a fase de projeto NTP, e fornecer uma capacidade da auditoria para uma arquitetura de NTP distribuída assegurando a conformidade a longo prazo o projeto pretendido.

Indicadores de desempenho do processo

Os indicadores de desempenho do processo são utilizados para medir a eficiência da definição do processo. Os indicadores de desempenho devem ser mensuráveis e determináveis. Por exemplo, os indicadores de desempenho alistados abaixo são numéricos ou medidos no tempo.

• O tempo necessário para fazer um ciclo por todo o processo.

• A frequência de execução exigida a fim detectar dinamicamente edições NTP antes que impactarem usuários.

• A carga da rede associada à execução do processo.

• O número de ações corretivas recomendadas pelo processo.

• O número de ações corretivas implementadas como resultado do processo.

• O período de tempo necessário para implementar ações corretivas.

• O acúmulo de ações corretivas.

• Os erros no Troubleshooting ou nos diagnósticos do problema atribuíram aos problemas relacionados NTP.

• O número de itens adicionados, removidos ou modificados no arquivo de seed. Essa é uma indicação de exatidão e estabilidade.

Entradas de processo

As entradas de processo são utilizadas para definir critérios e pré-requisitos de um processo. Muitas vezes, a identificação das entradas de processo fornece a informação em dependências externas. Uma lista de entradas relativas ao gerenciamento de NTP é fornecida abaixo.

• Documentação de projeto NTP

• Dados NTP MIB recolhidos pelo polling snmp

Saídas do processo

As saídas de processo são definidas abaixo:

• Relatórios da configuração de NTP definidos na seção da apresentação de dados deste papel

• Ações corretiva NTP

Definições de tarefas

As seguintes seções definem a iniciação e as tarefas repetitivas associadas com o gerenciamento de NTP.

Tarefas de inicialização

As tarefas de inicialização são executadas uma vez durante a aplicação do processo e não devem ser executadas durante cada iteração do processo.

Crie o projeto NTP

Na verificação de tarefas de pré-requisito, se for determinado que nenhuma das tarefas está implementada ou não fornece informações suficientes para servir com eficiência as necessidades desse procedimento, esse fato deverá ser documentado pelo proprietário do processo e enviado ao gerenciamento. A tabela abaixo descreve as tarefas de inicialização de pré-requisito.

Tarefa de pré-requisito	Descrição
Objetivos da tarefa	Crie um documento de design detalhado para a arquitetura de NTP que encontra requisitos de projeto e objetivos de custo
Entradas da tarefa	Exigências técnicas e econômicas do projeto Documentação do projeto de rede existente Critérios que definem os aspectos exigidos a ser gravados no projeto para permitir funções de gerenciamento Informação de desenvolvimento de aplicativo TI Exigências do monitoramento de desempenho
Saídas da tarefa	Documentação de projeto NTP
Recursos da tarefa	Arquiteto das operações de rede do arquiteto do engenheiro de rede
Papéis de tarefa	Aprovação técnica do projeto de rede custos do projeto de rede pelos revisores do planejamento e das operações aprovados pelo gerente responsável do orçamento

Criar um arquivo de seed

O processo do gerenciamento de NTP exige o uso de um arquivo de seed remover a necessidade para uma função de descoberta de rede. O arquivo de seed grava o conjunto de roteador que é governado pelo processo NTP e igualmente usado como um ponto focal para coordenar com os processos de gerenciamento de alteração em uma organização. Por exemplo, se os novos nós são incorporados na rede, precisam de ser adicionados ao arquivo de seed NTP. Se forem feitas alterações nos nomes da comunidade de SNMP devido a requisitos de segurança, essas modificações precisarão ser refletidas no arquivo de seed. A tabela abaixo resume os processos para criação de um arquivo de seed.

Tarefa de pré-requisito	Descrição
Objetivos da tarefa	Crie o arquivo de seed que identifica três categorias de dispositivos de rede Dispositivos críticos — Votado em uma base frequente para a informação de configuração Dispositivos interessantes — Votado menos frequentemente Todo o NTP permitiu dispositivos — Votou menos quantidade
Entradas da tarefa	Documentação de topologia de rede da documentação de projeto NTP
Saídas da tarefa	Arquivo de seed
Recursos da tarefa	Os critérios de projeto que serão usados para identificar e dar a prioridade aos Nós envolveram na arquitetura de NTP

Parâmetros de desempenho da linha de base NTP

Diversos dos parâmetros disponíveis para monitorar a exibição da rede NTP algumas variações normal esperadas. O processo de linha de base é usado para caracterizar as variações normal esperadas e para ajustar os pontos iniciais que definem inesperado ou condições anormais. Esta tarefa é usada à linha de base o conjunto variável dos parâmetros para a arquitetura de NTP. Para mais discussão detalhada da linha de base as técnicas consideram o processo de linha de base: White Paper de melhor prática.

Processo	Descrição
Objetivos da tarefa	Parâmetros variável da linha de base
Entradas da tarefa	Identifique do cntpPeersOffset cntpPeersRootDelay cntpSysRootDelay do cntpPeersRootDispersion do cntpSysRootDispersion dos parâmetros variável o cntpPeersDispersion cntpPeersDelay
Saídas de tarefa	Valores de linha de base e pontos iniciais
Recursos da tarefa	Ferramentas para recolher dados SNMP e linhas de base calculadoras
Função da tarefa	Coordenador nanômetros do engenheiro de rede

Tarefas repetidas

As tarefas repetitivas são executadas durante cada iteração do processo e sua frequência é determinada e alterada a fim melhorar os indicadores de desempenho.

Manter o arquivo de propagação

O arquivo de seed é crítico para a implementação eficaz do processo do gerenciamento de NTP. Portanto, o estado atual do arquivo de seed deve ser administrado ativamente. Muda à rede que impacta os índices da necessidade do arquivo de seed de ser seguido pelo proprietário de processo do gerenciamento de NTP.

Processo	Descrição
Objetivos da tarefa	Mantenha a precisão do arquivo de seed
Entradas da tarefa	Informação em alterações de rede
Saídas de tarefa	Arquivo de seed
Recursos da tarefa	Relatórios, notificações, reuniões a respeito das mudanças
Função da tarefa	Coordenador nanômetros do engenheiro de rede

Execute a varredura do nó NTP

Recolha a informação nas varreduras críticas, interessantes, e da configuração definidas por este procedimento. Execute estas três varreduras em frequências diferentes.

Os nós críticos são os dispositivos que são considerados como muito importantes para os pontos de dados da coleção do desempenho. A varredura do nó crítico é executada frequentemente, por exemplo, de hora em hora, ou em uma base da procura antes e depois das mudanças. Os nós interessantes são os dispositivos que são julgados importantes para a integridade total da arquitetura de NTP, mas não podem estar na árvore da sincronização de tempo para a coleção crítica dos dados de desempenho. Este relatório é executado periodicamente, por exemplo, diariamente ou mensalmente. Os relatórios de configuração são um relatório intenso detalhado e do recurso que seja usado para caracterizar a configuração de distribuição total NTP contra registros de projeto. Este relatório é executado menos frequentemente, por exemplo, mensal ou trimestral. Um ponto importante a considerar é que a frequência que os relatórios estão recolhidos pode ser ajustada com base na estabilidade observada da arquitetura de NTP e das necessidades de negócio.

Processo	Descrição
Objetivo da tarefa	Monitore a arquitetura de NTP
Entrada de tarefa	Dados do dispositivo de rede
Saídas da tarefa	Relatórios
Recursos da tarefa	Aplicativos de software recolher dados e relatórios do produto
Função da tarefa	Engenheiro de rede

Reveja os relatórios de nó NTP

Esta tarefa exige que o críticos, o interessantes, e relatórios de configuração estão revistos e analisados. Se as edições são detectadas, a seguir as ações corretiva devem ser iniciadas.

Processo	Descrição
Entradas da tarefa	Relatórios da varredura
Saídas de tarefa	Ações corretiva da análise de estabilidade
Recursos da tarefa	Alcance aos dispositivos de rede para investigações adicionais e verificação
Função da tarefa	Engenheiro de rede

Identificação de dados

Características de dados gerais

A tabela a seguir descreve os dados que são considerados interessantes para analisar a arquitetura de NTP.

Dados	Descrição
Identificação dos Nós	Um dispositivo que tenha o NTP configurado
Pares	Os peeres configurados para o dispositivo
Origem de sincronização	O par selecionado para a sincronização
Dados de configuração de NTP	Parâmetros usados para julgar a consistência do projeto NTP
Dados da qualidade NTP	Parâmetros usados para caracterizar a qualidade das associações NTP

Identificação de dados de SNMP

Grupo de sistema de Cisco NTP MIB

Os dados NTP SNMP são definidos pelo Cisco-NTP-MIB. Para obter informações atualizadas sobre das liberações que apoiam este MIB, usam a ferramenta de recurso de navegador CCO e selecionam a opção do localizador de MIB. Esta ferramenta é alcançada através das ferramentas tac para a página da Voz, da telefonia e das tecnologias de mensagens.

O grupo de sistema em Cisco NTP MIB fornece a informação para o nó de destino que executa o NTP. O nó de destino é o destino das perguntas SNMP.

Nome do objeto	Descrição do objeto
cntpSysStratum	O estrato do relógio local. Se o valor é ajustado a 1, uma referência principal, a seguir o procedimento do Relógio principal descritos na seção 3.4.6, no RFC-1305 estão invocados. :: = identificador de objeto do {cntpsystem 2} = .1.3.6.1.4.1.9.9.168.1.1.2
cntpSysPrecision	Integer assinado que indica a precisão do relógio de sistema, nos segundos, à potência a mais próxima de dois. O valor deve ser arredondado à potência maior seguinte de dois. Por exemplo, (Senhora 16.67) um pulso de disparo da potência-frequência 50-Hz (Senhora 20) ou 60-Hz é atribuído o valor -5 (Senhora 31.25), quando (1 Senhora) um pulso de disparo 1000-Hz cristal-controlado for atribuído o valor -9 (Senhora 1.95). :: = identificador de objeto do {cntpsystem 3} = .1.3.6.1.4.1.9.9.168.1.1.3
cntpSysRootDelay	Um número de ponto fixo assinado que indica o retardo round trip total nos segundos, ao origem da referência principal na raiz da sub-rede de sincronização. :: = identificador de objeto do {cntpsystem 4} = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRootDispersion	O erro máximo nos segundos, relativo ao origem da referência principal na raiz da sub-rede de sincronização. Somente os valores positivos maiores de zero são possíveis. :: = identificador de objeto do {cntpsystem 5} = .1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRefTime	O horário local em que o relógio local foi atualizado por último. Se o relógio local foi sincronizado nunca, o valor é zero. :: = identificador de objeto do {cntpsystem 7} = .1.3.6.1.4.1.9.9.168.1.1.7
cntpSysPeer	O origem de sincronização atual que contém o cntpPeersAssocId do identificador de associação exclusivo da entrada correspondente do par no cntpPeersVarTable do par que atua como o origem de sincronização. Se não há nenhum par, o valor é zero. :: = identificador de objeto do {cntpsystem 9} = .1.3.6.1.4.1.9.9.168.1.1.9
cntpSysClock	O horário local atual. O horário local é derivado do relógio de hardware da máquina e dos incrementos particulares em intervalos segundo o projeto usado. :: = identificador de objeto do {cntpsystem 10} = .1.3.6.1.4.1.9.9.168.1.1.10

Peer-group de Cisco NTP MIB - Tabela variável dos pares

O peer-group de Cisco NTP MIB fornece a informação nos pares do nó de destino.

Nome do objeto	Descrição do objeto
cntpPeersVarTable	Esta tabela fornece a informação nos pares com que o servidor de NTP local tem associações. Os pares são igualmente servidores de NTP que são executado em anfitriões diferentes. Esta é uma tabela de cntpPeersVarEntry:: = identificador de objeto do {cntppeers 1} = .1.3.6.1.4.1.9.9.168.1.2.1
cntpPeersVarEntry	Cada entrada dos pares fornece a informação de NTP recuperada de um servidor de NTP do peer particular. Cada par é identificado por um identificador de associação exclusivo. As entradas são criadas automaticamente quando o usuário configura o servidor de NTP a ser associado com os peer remotos. Similarmente, as entradas são suprimidas quando o usuário remove a associação de peer do servidor de NTP. As entradas podem igualmente ser criadas pela estação de gerenciamento por valores de ajuste para cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode e fatura do cntpPeersEntryStatus como o active (1). Pelo menos, a estação de gerenciamento tem que ajustar um valor para que os cntpPeersPeerAddress façam o active da fileira. {cntpPeersAssocId} do DESLOCAMENTO PREDETERMINADO:: = identificador de objeto do {cntppeersvartable 1} = .1.3.6.1.4.1.9.9.168.1.2.1.1
cntpPeersAssocId	Um valor de número inteiro maior de zero que identifica excepcionalmente um par com que o servidor de NTP local é associado. :: = identificador de objeto do {cntppeersvarentry 1} = .1.3.6.1.4.1.9.9.168.1.2.1.1.1
cntpPeersConfigured	Este é um bit que indica que a associação esteve criada da informação de configuração e não deve ser deassociated mesmo se o par se torna inacessível. :: = identificador de objeto do {cntppeersvarentry 2} = .1.3.6.1.4.1.9.9.168.1.2.1.1.2
cntpPeersPeerAddress	O IP address do par. Ao criar uma associação nova, um valor para este objeto deve ser ajustado antes que a fileira esteja feita a active. :: = identificador de objeto do {cntppeersvarentry 3} = .1.3.6.1.4.1.9.9.168.1.2.1.1.3
cntpPeersMode	(1) não especificado (0), symmetricActive do NÚMERO INTEIRO DE SINTAXE {, (2) symmetricPassive, cliente (3), server (4), transmissão (5), reservedControl (6), reservedPrivate (7)} ao criar uma associação de peer nova, se nenhum valor está especificado para este objeto, opta (1) symmetricActive. :: = identificador de objeto do {cntppeersvarentry 8} = .1.3.6.1.4.1.9.9.168.1.2.1.1.8
cntpPeersStratum	O estrato do pulso de disparo do par. :: = identificador de objeto do {cntppeersvarentry 9} = .1.3.6.1.4.1.9.9.168.1.2.1.1.9
cntpPeersRootDelay	Um número de ponto fixo assinado que indica o retardo round trip total nos segundos, do par ao origem da referência principal na raiz da sub-rede de sincronização. :: = identificador de objeto do {cntppeersvarentry 13} = .1.3.6.1.4.1.9.9.168.1.2.1.1.13
cntpPeersRootDispersion	O erro máximo, nos segundos, do pulso de disparo do par relativo ao origem da referência principal na raiz da sub-rede de sincronização. Somente os valores positivos maiores de zero são possíveis. :: = identificador de objeto do {cntppeersvarentry 14} = .1.3.6.1.4.1.9.9.168.1.2.1.1.14
cntpPeersRefTime	O horário local no par quando seu pulso de disparo foi atualizado por último. Se o pulso de disparo do par foi sincronizado nunca, o valor é zero. :: = identificador de objeto do {cntppeersvarentry 16} = .1.3.6.1.4.1.9.9.168.1.2.1.1.16
cntpPeersReach	Um registrador de deslocamento usado para determinar o estado do reachability do par, com os bit que entram da extremidade (rightmost) o mais menos significativa. Um par está considerado alcançável se pelo menos um bit neste registro é ajustado a um (o objeto é diferente de zero). Os dados no registrador de deslocamento são povoados pelos procedimentos do protocolo NTP. :: = identificador de objeto do {cntppeersvarentry 21} = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersOffset	O offset calculado do pulso de disparo do par relativo ao relógio local, nos segundos. O host determina o valor deste objeto usando o algoritmo de filtro de relógio NTP. :: = identificador de objeto do {cntppeersvarentry 23} = .1.3.6.1.4.1.9.9.168.1.2.1.1.21
cntpPeersDelay	O retardo round trip calculado do pulso de disparo do par relativo ao relógio local sobre o caminho de rede entre eles, nos segundos. O host determina o valor deste objeto usando o algoritmo de filtro de relógio NTP. :: = identificador de objeto do {cntppeersvarentry 24} = .1.3.6.1.4.1.9.9.168.1.2.1.1.24
cntpPeersDispersion	O erro máximo calculado do pulso de disparo do par relativo ao relógio local sobre o caminho de rede entre eles, nos segundos. O host determina o valor deste objeto usando o algoritmo de filtro de relógio NTP. :: = identificador de objeto do {cntppeersvarentry 25} = .1.3.6.1.4.1.9.9.168.1.2.1.1.25

Levantamento de dados

Levantamento de dados de SNMP

Toda a informação exigida por este procedimento pode ser recolhida com as perguntas SNMP. A fim analisar gramaticalmente os dados e produzir os relatórios, os scripts personalizados ou os programas do software terão que ser desenvolvidos.

Apresentação de dados

Relatório de nó crítico do NTP

Os nós críticos são os dispositivos que são importantes na árvore de sincronização de pontos de coleção de dados de desempenho selecionados. Se há um serviço voip alto do rendimento que está sendo monitorado e medidor da um-maneira-atraso-variação está sendo recolhida, a seguir os nós de origem e de destino onde os marcadores temporais são gravados são considerados nós críticos.

Neste exemplo, o projeto NTP foi estabelecido depois de uma hierarquia do exemplo OSPF. Consequentemente, os relatórios descritos abaixo são formatados para agrupar os dispositivos NTP de acordo com a área do OSPF do dispositivo. Nos casos onde um nó tem relações nas áreas múltiplas, uma decisão deve ser feita pelo software da geração de relatório a respeito de que área o nó estará listado para finalidades do relatório. Como mencionado mais cedo, o OSPF não é uma condição prévia para o NTP. É usado somente neste papel como um exemplo ilustrativo.

Área	Dispositivo	Dados de dispositivo	Valor
#n de AreaId	DeviceId #1	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		cntpSysRefTime
		cntpSysPeer
		cntpSysClock
	#n de DeviceId	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		cntpSysRefTime
		cntpSysPeer
		cntpSysClock

Relatório de nó interessante do NTP

O formato dos relatórios de nó interessante é o mesmo que o formato para os relatórios de nó crítico. Os nós interessantes são os Nós que são considerados importantes para a arquitetura geral de NTP, mas não podem diretamente contribuir à sincronização de tempo de pontos de monitoramento de desempenho críticos.

Relatório de configuração NTP

Os relatórios de configuração são um relatório detalhado que recolha a informação na arquitetura geral de NTP. Este relatório é usado para gravar e verificar o desenvolvimento NTP contra registros de projeto.

Área	Dispositivo	Par	Dados do par	Valor
#n de AreaId	#n de DeviceId	PeerId #1	cntpPeersAssocId
			cntpPeersConfigured
			cntpPeersPeerAddress
			cntpPeersMode
			cntpPeersStratum
			cntpPeersRootDelay
			cntpPeersRootDispersion
			cntpPeersRefTime
			cntpPeersReach
			cntpPeersOffset
			cntpPeersDelay
			cntpPeersDispersion
		#n de PeerId	cntpPeersAssocId
			cntpPeersConfigured
			cntpPeersPeerAddress
			cntpPeersMode
			cntpPeersStratum
			cntpPeersRootDelay
			cntpPeersRootDispersion
			cntpPeersRefTime
			cntpPeersReach
			cntpPeersOffset
			cntpPeersDelay
			cntpPeersDispersion

Informações Relacionadas

• Protocolo Network Time Protocol do RFC 1305
• Estrutura do RFC 2330 para métricos de desempenho IP
• Os IO essenciais caracterizam cada ISP devem considerar v2.84
• Suporte Técnico - Cisco Systems