Use as práticas recomendadas para o Network Time Protocol
Contents
Introduction
Este documento descreve as melhores práticas para projetar o Network Time Protocol.
Prerequisites
Requirements
A Cisco recomenda ter conhecimento deste tópico:
- Protocolo de tempo de rede
- Tecnologia de relógio e servidores de tempo público
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
As redes baseadas em Internet Protocol (IP) avançaram rapidamente do modelo tradicional de melhor esforço de entrega para um modelo em que o desempenho e a confiabilidade precisam ser quantificados e, em muitos casos, garantidos com Service Level Agreements (SLAs). A necessidade de uma maior compreensão das características da rede levou a esforços significativos de pesquisa direcionados a métricas importantes e recursos de medição para caracterizar o comportamento da rede. A base de muitas metodologias de métrica é a medição do tempo.
A sincronização do tempo da rede, no grau necessário para a análise de desempenho moderna, é um exercício essencial. Com base nos modelos de negócios e nos serviços fornecidos, a caracterização do desempenho da rede é considerada um importante diferencial de serviço competitivo. Nesses casos, uma grande despesa é incorrida quando você implanta sistemas de gerenciamento de rede e recursos de engenharia diretos para analisar os dados de desempenho coletados. No entanto, se não for dada a devida atenção ao princípio, muitas vezes ignorado, da sincronização de tempo, esses esforços serão ineficazes.
Este documento descreve uma definição de processo hipotético para gerenciamento de função de gerenciamento de rede para o Network Time Protocol (NTP). Você pode usar este artigo como um procedimento hipotético e um exemplo informativo. Isso pode ser personalizado por uma organização para atender a objetivos internos.
As informações fornecidas por este documento são apresentadas em várias seções principais:
- A seção Terminologia fornece definições gerais de termos sobre sincronização de tempo.
- A seção Visão Geral fornece informações básicas sobre o hardware do elemento de rede relacionado ao tempo do sistema, uma visão geral tecnológica do NTP e os principais aspectos do projeto da arquitetura do NTP.
- A seção Exemplo de Implantação de NTP fornece exemplos de implantação de NTP com configurações de exemplo para WAN, campus de estrato alto e redes de distribuição de tempo de campus de estrato baixo.
- A seção Definições do Processo fornece uma visão geral das definições de processo usadas para realizar o gerenciamento do NTP. Os detalhes do processo são descritos em termos de metas, indicadores de desempenho, entradas, saídas e tarefas individuais.
- A seção Definições de Tarefa fornece definições detalhadas de tarefas de processo. Cada tarefa é descrita em termos de objetivos, entradas e saídas de tarefas, recursos necessários para realizar a tarefa e habilidades de trabalho necessárias para um implementador de tarefas.
- A seção Identificação de Dados descreve a identificação de dados para NTP. A identificação dos dados considera a fonte das informações. Por exemplo, as informações podem ser contidas na Base de Informações de Gerenciamento (MIB - Management Information Base) do Protocolo de Gerenciamento de Rede Simples (SNMP - Simple Network Management Protocol), em arquivos de log gerados pelo Syslog ou em estruturas de dados internas que só podem ser acessadas pela interface de linha de comando (CLI - Command Line Interface).
- A seção Data Collection descreve a coleta dos dados de 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 coletados por scripts automáticos ou quando um usuário faz login manualmente no sistema para emitir o comando CLI e registrar a saída.
- A seção Data Presentationfornece exemplos de formato de relatório de como os dados podem ser apresentados.
Terminology
-
Precisão — A proximidade do valor absoluto do relógio com o deslocamento de zero.
-
Precisa — Quando um deslocamento de relógio é zero em um momento específico.
-
Desvio — A medida na variação de desvio ou a segunda derivação do deslocamento do relógio em relação ao tempo.
-
Resolução conjunta — Quando os relógios são comparados, é a soma das resoluções de C1 e C2. A resolução conjunta então indica um limite inferior conservador na precisão de qualquer intervalo de tempo calculado por carimbos de data/hora gerados por um relógio subtraído daqueles gerados pelo outro.
-
Nó — Refere-se a uma instanciação do protocolo NTP em um processador local. Um nó também pode ser chamado de dispositivo.
-
Deslocamento — A diferença entre a hora relatada por um relógio e a hora real, conforme definido pelo Tempo Universal Coordenado (UTC). Se o relógio informar um tempo Tc e o tempo verdadeiro for Tt, o deslocamento do relógio será Tc - Tt.
-
Peer — Refere-se a uma instanciação do protocolo NTP em um processador remoto conectado por um caminho de rede do nó local.
-
Deslocamento relativo — A noção de tempo real é substituída pelo tempo como relatado pelo relógio C1, quando dois relógios, C1 e C2, são comparados. Por exemplo, o deslocamento do relógio C2 em relação a C1 em um momento específico é Tc2 - Tc1, a diferença instantânea de tempo relatada por C2 e C1.
-
Resolução — A menor unidade pela qual um tempo de clock é atualizado. A resolução é definida em termos de segundos. No entanto, a resolução é relativa ao tempo relatado do relógio e não ao tempo real. Por exemplo, uma resolução de 10 milissegundos significa que o relógio atualiza sua noção de tempo em incrementos de 0,01 segundo e não significa que essa é a quantidade real de tempo entre as atualizações.
-
Desvio — Uma diferença de frequência de relógio, ou a primeira derivada de seu deslocamento em relação ao tempo.
-
Sincronizar — Quando dois relógios são precisos um em relação ao outro (o deslocamento relativo é zero), eles são sincronizados. Os relógios podem ser sincronizados e ainda imprecisos em termos de quão bem eles dizem o tempo verdadeiro.
Overview
Visão geral do dispositivo
O coração do serviço de tempo é o relógio do sistema. O relógio do sistema é executado a partir do momento em que o sistema é iniciado e controla a data e a hora atuais. O relógio do sistema pode ser definido a partir de várias fontes e, por sua vez, pode ser usado para distribuir a hora atual através de vários mecanismos para outros sistemas. Alguns roteadores contêm um sistema de calendário alimentado por bateria que rastreia a data e a hora em reinicializações do sistema e interrupções de energia. Este sistema de calendário é sempre usado para inicializar o relógio do sistema quando o sistema é reiniciado. Ele também pode ser considerado como uma fonte de tempo autorizada e redistribuído através do NTP se nenhuma outra fonte estiver disponível. Além disso, se o NTP estiver habilitado, o calendário é atualizado periodicamente a partir do NTP, e isso compensa a deriva inerente no tempo do calendário. Quando um roteador com um calendário de sistema é inicializado, o relógio do sistema é ajustado com base na hora em seu calendário interno alimentado por bateria. Em modelos sem calendário, o relógio do sistema é definido como uma constante de tempo predeterminada. O relógio do sistema pode ser definido a partir das fontes listadas a seguir.
-
NTP
-
SNTP (Simple Network Time Protocol, protocolo simples de horário de rede)
-
Serviço de tempo Virtual Integrated Network Service (VINES)
-
Configuração manual
Determinados dispositivos Cisco low-end suportam apenas SNTP. O SNTP é uma versão simplificada do NTP somente para o cliente. O SNTP só pode receber o tempo dos servidores NTP e não pode ser usado para fornecer serviços de tempo a outros sistemas. O SNTP normalmente fornece tempo dentro de 100 milissegundos do tempo exato. Além disso, o SNTP não autentica o tráfego, embora você possa configurar listas de acesso estendidas para fornecer alguma proteção. Um cliente SNTP é mais vulnerável a servidores fora de conformidade do que um cliente NTP e só deve ser usado em situações em que a autenticação forte não é necessária.
O relógio do sistema fornece tempo para os serviços listados a seguir.
-
NTP
-
serviço de tempo VINES
-
Comandos deexibiçãousuário
-
Registrando e depurando mensagens
O relógio do sistema monitora o horário internamente com base no UTC, também conhecido como Hora de Greenwich (GMT). Você pode configurar informações sobre o fuso horário local e o horário de verão para que a hora seja exibida corretamente em relação ao fuso horário local. O relógio do sistema controla se a hora é oficial ou não. Se não for autoritativa, a hora poderá estar disponível apenas para fins de exibição e não poderá ser redistribuída.
Visão geral do NTP
O NTP é projetado para sincronizar a hora em uma rede de máquinas. O NTP é executado no User Datagram Protocol (UDP), com a porta 123 como origem e destino, que, por sua vez, é executada no IP. O NTP versão 3RFC 1305é usado para sincronizar a manutenção de tempo entre um conjunto de servidores e clientes de tempo distribuídos. Um conjunto de nós em uma rede é identificado e configurado com NTP e os nós formam uma sub-rede de sincronização, às vezes chamada de rede de sobreposição. Embora vários servidores principais possam existir, não há necessidade de um protocolo de eleição.
Uma rede NTP geralmente obtém seu tempo de uma fonte de tempo autorizada, como um rádio-relógio ou um relógio atômico conectado a um servidor de tempo. Em seguida, o NTP distribui esse tempo pela rede. Um cliente NTP faz uma transação com seu servidor durante seu intervalo de polling (de 64 a 1024 segundos) que muda dinamicamente ao longo do tempo, dependendo das condições de rede entre o servidor NTP e o cliente. A outra situação ocorre quando o roteador se comunica com um servidor NTP inválido (por exemplo, servidor NTP com grande dispersão); o roteador também aumenta o intervalo de poll. Não é necessária mais de uma transação NTP por minuto para sincronizar duas máquinas. Não é possível ajustar o intervalo de eleição NTP em um roteador.
O NTP usa o conceito de um stratum para descrever quantos saltos de distância NTP uma máquina está de uma fonte de tempo autoritativa. Por exemplo, um servidor de tempo stratum 1 tem um rádio ou relógio atômico diretamente conectado a ele. Em seguida, ele envia seu horário para um servidor de horário de estrato 2 através do NTP e assim por diante. Uma máquina que executa o NTP escolhe automaticamente a máquina com o número de stratum mais baixo que está configurada para se comunicar com o NTP como sua origem de tempo. Essa estratégia cria efetivamente uma árvore auto-organizada de alto-falantes NTP. O NTP tem um bom desempenho sobre os comprimentos de caminho não determinísticos de redes comutadas por pacotes, pois faz estimativas robustas das três variáveis-chave seguintes na relação entre um cliente e um servidor de tempo.
-
Atraso de rede
-
Dispersão de trocas de pacotes de tempo — Uma medida do erro de relógio máximo entre os dois hosts.
-
Deslocamento do relógio—A correção aplicada a um relógio do cliente para sincronizá-lo.
A sincronização de relógio no nível de 10 milissegundos em redes de longa distância (WANs) (2000 km) e no nível de 1 milissegundo para redes locais (LANs) é obtida rotineiramente.
Há duas maneiras pelas quais o NTP não é sincronizado com uma máquina cuja hora não é precisa. Em primeiro lugar, o NTP nunca sincroniza com uma máquina que não esteja sincronizada. Em segundo lugar, o NTP compara o tempo relatado por várias máquinas e não sincroniza com uma máquina cujo tempo é significativamente diferente dos outros, mesmo que seu estrato seja menor.
As comunicações entre máquinas que executam NTP (associações) são geralmente configuradas estaticamente. Cada máquina recebe o endereço IP de todas as máquinas com as quais deve formar associações. A cronometragem precisa é possibilitada por mensagens NTP trocadas entre cada par de máquinas com uma associação. No entanto, em um ambiente de LAN, o NTP pode ser configurado para usar mensagens de broadcast IP. Essa alternativa reduz a complexidade da configuração porque cada máquina pode ser configurada para enviar ou receber mensagens de broadcast. No entanto, a precisão da cronometragem é reduzida marginalmente porque o fluxo de informações é apenas unidirecional.
O tempo mantido em uma máquina é um recurso crítico e é altamente recomendável que você use os recursos de segurança do NTP para evitar a configuração acidental ou mal-intencionada de tempo incorreto. Os dois recursos de segurança disponíveis são um esquema de restrição baseado em lista de acesso e um mecanismo de autenticação criptografado.
A implementação de NTP da Cisco suporta o serviço de estrato 1 em certas versões do software Cisco IOS®. Se uma versão suporta o comando thentp refclockcommand, é possível conectar um rádio ou relógio atômico. Determinadas versões do Cisco IOS suportam o Kit de Sincronização NTP Trimble Palisade (somente roteadores da série Cisco 7200) ou o dispositivo Telecom Solutions Global Positioning System (GPS). Se a rede usar os servidores de horário público na Internet e a rede estiver isolada da Internet, a implementação de NTP da Cisco permite que uma máquina seja configurada de modo que ela atue como se estivesse sincronizada através do NTP, quando na verdade ela determinou o horário por outros meios. Em seguida, outras máquinas são sincronizadas com essa máquina através do NTP.
Critérios de padrão NTP
Cada cliente na sub-rede de sincronização, que também pode ser um servidor para clientes stratum mais altos, escolhe um dos servidores disponíveis para sincronizar. Isso geralmente ocorre entre os servidores de estrato mais baixos aos quais ele tem acesso. No entanto, essa nem sempre é uma configuração ideal, pois o NTP também opera sob a premissa de que cada horário do servidor deve ser visto com uma certa desconfiança. O NTP prefere ter acesso a várias fontes de tempo de estrato mais baixo (pelo menos três), pois pode então aplicar um algoritmo de acordo para detectar insanidade por parte de qualquer um desses. Normalmente, quando todos os servidores estão de acordo, o NTP escolhe o melhor servidor em termos de estrato mais baixo, mais próximo (em termos de atraso de rede) e precisão reivindicada. A implicação é que, enquanto se deve ter como objetivo fornecer a cada cliente três ou mais origens de tempo de estrato mais baixo, várias delas só podem fornecer serviço de backup e podem ser de menor qualidade em termos de atraso de rede e estrato. Por exemplo, um peer de mesmo estrato que recebe tempo de origens de estrato mais baixo que o servidor local não acessa diretamente também pode fornecer um bom serviço de backup.
O NTP geralmente prefere servidores de estrato mais baixos a servidores de estrato mais altos, a menos que o tempo do servidor de estrato mais baixo seja significativamente diferente. O algoritmo é capaz de detectar quando uma fonte de tempo é susceptível de ser extremamente imprecisa, ou insana, e para evitar a sincronização nesses casos, mesmo se o relógio impreciso está em um nível de estrato inferior. E ele nunca pode sincronizar um dispositivo com outro servidor que não esteja sincronizado sozinho.
Para declarar se o servidor é confiável, ele precisa passar por várias verificações de sanidade, como:
-
As implementações devem incluir tempos limite de sanidade que impeçam transmissões de interceptação (trapping) se o programa de monitoramento não renovar essas informações após um intervalo longo.
-
Verificações adicionais de integridade são incluídas para autenticação, limites de intervalo e para evitar o uso de dados muito antigos.
-
Foram adicionadas verificações para avisar que o oscilador ficou muito tempo sem atualização de uma fonte de referência.
-
As variáveis peer.valid e sys.hold foram adicionadas para evitar instabilidades quando a origem de referência muda rapidamente devido a grandes atrasos dispersivos sob condições de grave congestionamento de rede. Os bits peer.config, peer.authenable e peer.authentic foram adicionados para controlar recursos especiais e simplificar a configuração.
Se pelo menos uma dessas verificações falhar, o roteador a declarará insana.
Modos de associação
As próximas seções descrevem os modos de associação usados pelos servidores NTP para se associarem.
-
Cliente/Servidor
-
Simétrico ativo/passivo
-
Broadcast
Modo cliente/servidor
Clientes e servidores dependentes normalmente operam no modo cliente/servidor, no qual um cliente ou servidor dependente pode ser sincronizado com um membro do grupo, mas nenhum membro do grupo pode sincronizar com o cliente ou servidor dependente. Isso fornece proteção contra mau funcionamento ou ataques de protocolo.
O modo cliente/servidor é a configuração de Internet mais comum. Ele opera no paradigma clássico de chamada de procedimento remoto (RPC) com servidores stateless. Nesse modo, um cliente envia uma solicitação ao servidor e espera uma resposta em algum momento futuro. Em alguns contextos, isso seria descrito como uma operação de pesquisa, na qual o cliente pesquisa a hora e os dados de autenticação do servidor. Um cliente é configurado no modo cliente com o comando server e com o nome ou endereço do servidor de nomes de domínio (DNS) especificado. O servidor não requer configuração prévia.
Em um modelo cliente/servidor comum, um cliente envia uma mensagem NTP a um ou mais servidores e processa as respostas como recebidas. O servidor troca endereços e portas, substitui determinados campos na mensagem, recalcula o checksum e retorna a mensagem imediatamente. As informações incluídas na mensagem NTP permitem que o cliente determine a hora do servidor em relação à hora local e ajuste o relógio local conforme necessário. Além disso, a mensagem inclui informações para calcular a precisão e a confiabilidade esperadas da cronometragem, bem como selecionar o melhor servidor.
Os servidores que fornecem sincronização para uma população considerável de clientes normalmente operam como um grupo de três ou mais servidores mutuamente redundantes e cada um opera com três ou mais servidores de estrato 1 ou estrato 2 em modos cliente/servidor, bem como todos os outros membros do grupo em modos simétricos. Isso fornece proteção contra mau funcionamento no qual um ou mais servidores falham ao operar ou fornecem tempo incorreto. Os algoritmos NTP são projetados para resistir a ataques quando alguma fração das fontes de sincronização configuradas fornece, acidental ou propositalmente, tempo incorreto. Nesses casos, um procedimento especial de votação é usado para identificar fontes falsas e descartar seus dados. Por questões de confiabilidade, os hosts selecionados podem ser equipados com relógios externos e usados para backup em caso de falha dos servidores primário e/ou secundário ou dos caminhos de comunicação entre eles.
A configuração de uma associação no modo cliente é geralmente indicada por uma declaração de servidor no arquivo de configuração e indica que você deseja obter tempo do servidor remoto, mas que não deseja fornecer tempo ao servidor remoto.
Modo simétrico ativo/passivo
O modo simétrico ativo/passivo destina-se a configurações em que um grupo de pares de estrato baixo opera como backups mútuos entre si. Cada peer opera com uma ou mais fontes de referência primárias, como um relógio de rádio, ou um subconjunto de servidores secundários confiáveis. Se um dos peers perder todas as fontes de referência ou simplesmente parar a operação, os outros peers serão automaticamente reconfigurados para que os valores de tempo possam fluir dos peers atuais para todos os outros na fila. Em alguns contextos, isso é descrito como apush-pulloperation, em que o peer puxa ou empurra o tempo e os valores com base na configuração particular.
A configuração de uma associação em modo simétrico-ativo, geralmente indicada por uma declaração de peer no arquivo de configuração, indica ao servidor remoto que se deseja obter tempo do servidor remoto e que também se deseja fornecer tempo ao servidor remoto, se necessário. Este modo é apropriado em configurações que envolvem um número de servidores de tempo redundantes interconectados através de diversos caminhos de rede, o que é atualmente o caso para a maioria dos servidores de estrato 1 e estrato 2 na Internet atualmente.
Os modos simétricos são usados com mais frequência entre dois ou mais servidores que operam como um grupo mutuamente redundante. Nesses modos, os servidores nos membros do grupo organizam os caminhos de sincronização para obter o máximo desempenho, com base no atraso de propagação e na instabilidade da rede. Se um ou mais dos membros do grupo falhar, os membros residuais serão automaticamente reconfigurados conforme necessário.
Um peer é configurado no modo ativo simétrico com opeercommand e quando o nome DNS ou o endereço do outro peer é especificado. O outro peer também é configurado no modo ativo simétrico dessa maneira.
Modo de broadcast e/ou multicast
Quando os requisitos de precisão e confiabilidade são modestos, os clientes podem ser configurados para usar os modos broadcast e/ou multicast. Normalmente, esses modos não são utilizados por servidores com clientes dependentes. A vantagem é que os clientes não precisam ser configurados para um servidor específico, e isso permite que todos os clientes operacionais usem o mesmo arquivo de configuração. O modo de difusão requer um servidor de difusão na mesma sub-rede. Como as mensagens de broadcast não são propagadas pelos roteadores, somente os servidores de broadcast na mesma sub-rede são usados.
O modo de broadcast é destinado a configurações que envolvem um ou alguns servidores e uma população de clientes potencialmente grande. Um servidor de broadcast é configurado com o comando broadcast e um endereço de sub-rede local. Um cliente de broadcast é configurado com o comando broadcastclientque permite que o cliente de broadcast responda às mensagens de broadcast recebidas em qualquer interface. Como um invasor pode representar um servidor de broadcast e injetar valores de tempo falsos, esse modo deve sempre ser autenticado.
Definir salto de NTP em segundo
Você pode usar o comando ip leap {add|delete}para inserir um segundo leap. Há opções para adicionar ou excluir segundos bissextos. Há duas restrições para que isso ocorra:
-
O relógio deve estar no estado sincronizado.
-
O comando é aceito somente no mês anterior à ocorrência do salto. Ele não pode definir o salto se a hora atual for anterior a 1 mês da ocorrência do salto.
Depois de configurá-lo, o segundo salto é adicionado ou excluído para o ú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 occurring 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
Essas três estruturas estão disponíveis para a arquitetura NTP:
-
Estrutura de peer linear
-
Estrutura hierárquica
-
Estrutura em estrela
Em uma estrutura de peer linear, todos os roteadores fazem peer entre si, com alguns roteadores geograficamente separados configurados para apontar para sistemas externos. A convergência de tempo se torna mais longa com cada novo membro da malha de NTP.
Em uma estrutura hierárquica, a hierarquia de roteamento é copiada para a hierarquia NTP. Os roteadores centrais têm uma relação cliente/servidor com fontes de tempo externas, os servidores de tempo internos têm uma relação cliente/servidor com os roteadores centrais, os roteadores de usuário interno (servidores que não são de tempo) têm uma relação cliente/servidor com os servidores de tempo internos e assim por diante na árvore. Esses relacionamentos são chamados de escalas hierárquicas. Uma estrutura hierárquica é a técnica preferida porque fornece consistência, estabilidade e escalabilidade.
Uma arquitetura NTP escalável tem uma estrutura hierárquica como visto no próximo diagrama.
Arquitetura NTP escalável
Em uma estrutura em estrela, todos os roteadores têm uma relação cliente/servidor com alguns servidores de tempo no núcleo. Os servidores de tempo dedicados são o centro da estrela e são geralmente sistemas UNIX sincronizados com fontes de tempo externas, ou seu próprio receptor GPS.
Tecnologia de relógio e servidores de tempo público
A sub-rede NTP da Internet inclui atualmente mais de 50 servidores primários públicos sincronizados diretamente com o UTC por rádio, satélite ou 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 com os servidores primários e fornecem sincronização para um total superior a 100.000 clientes e servidores na Internet. As listas de servidores de horário NTP públicos são atualizadas com frequência. Há também vários servidores primários e secundários privados que normalmente não estão disponíveis para o público.
Em certos casos, onde serviços de tempo altamente precisos são necessários na empresa privada, como métricas unidirecionais para medições de Voz sobre IP (VoIP), os projetistas de rede podem optar por implantar fontes de tempo externas privadas. O próximo diagrama mostra um gráfico comparativo da precisão relativa das tecnologias atuais.
Gráfico comparativo
Até recentemente, o uso de fontes de tempo externas não era amplamente implantado em redes corporativas devido ao alto custo de fontes de tempo externas de qualidade. No entanto, à medida que os requisitos de Qualidade de Serviço (QoS) aumentam e o custo do tempo que a tecnologia continua a diminuir, as fontes de tempo externas para redes corporativas são uma opção viável.
Exemplo de implantações de NTP
Rede de distribuição de tempo WAN
No próximo diagrama, um sistema autônomo (AS) corporativo obtém informações de tempo de três servidores de tempo públicos. O AS corporativo é mostrado como servidores de tempo da Área 0 e da Área 1. Neste exemplo, a hierarquia NTP segue a hierarquia OSPF (Open Shortest Path First). No entanto, o OSPF não é um pré-requisito para o NTP. Ele é usado apenas como um exemplo ilustrativo. O NTP pode ser implantado ao longo de outros limites hierárquicos lógicos, como uma hierarquia Enhanced Interior Gateway Routing Protocol (EIGRP) ou a hierarquia padrão Core/Distribution/Access.
Rede de distribuição de tempo WAN
Este exemplo é a configuração do Cisco IOS para o dispositivo A0-R1 como mostrado no diagrama anterior.
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 can be allowed to update the calendar
!--- and Cisco IOS can be configured to be an
!--- NTP master clock source.
!--- Cisco IOS can 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 can obtain the
!--- clock from the hardware calendar based on
!--- the previous line. This line can 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 descrevia uma rede de distribuição de tempo de WAN. Esta seção desce uma etapa na hierarquia para discutir a distribuição de tempo em uma rede de campus de estrato alto.
A principal diferença considerada para a distribuição de tempo em uma rede de campus de alto estrato é o uso potencial do modo de associação de broadcast. Conforme descrito anteriormente, o modo de associação de broadcast simplifica as configurações para as LANs, mas reduz a precisão dos cálculos de tempo. Portanto, a compensação nos custos de manutenção deve ser considerada em relação à precisão nas medidas de desempenho.
Rede de distribuição de tempo de campus de alto estrato
A rede de campus de estrato alto, mostrada no diagrama acima, é retirada do projeto de rede padrão do Cisco Campus e contém três componentes. O núcleo do campus consiste em dois dispositivos de Camada 3 rotulados CB-1 e CB-2. O componente do servidor, localizado na seção inferior da figura, tem dois roteadores de Camada 3 rotulados como SD-1 e SD-2. Os outros dispositivos no bloco do servidor são dispositivos da camada 2. No canto superior esquerdo, há um bloco de acesso padrão com dois dispositivos de distribuição de Camada 3 rotulados como dl-1 e dl-2. O restante dos dispositivos são switches de Camada 2. Neste bloco de acesso do cliente, o tempo é distribuído com a opção de broadcast. No canto superior direito, há outro bloco de acesso padrão que usa uma configuração de distribuição de tempo cliente/servidor.
Os dispositivos de backbone do campus são sincronizados com os servidores de horário de área em um modelo cliente/servidor.
Esta é a configuração para os dispositivos de distribuição de camada 3 dl-1:
!--- In this case, dl-1 can 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 a seguir, uma fonte de tempo GPS ou Cesium é fornecida no data center central para a rede de campus de camada baixa. Isso provisiona uma fonte de tempo de estrato 1 na rede privada. Se houver várias fontes de tempo GPS ou Cesium localizadas na rede privada, a distribuição de tempo na rede privada deverá ser modificada para aproveitar as fontes de tempo disponíveis.
Em geral, os mesmos princípios e configurações se aplicam como nos exemplos anteriores. A principal diferença neste caso é que a raiz da árvore de sincronização é uma fonte de tempo privada em vez de uma fonte de tempo pública da Internet. Isso altera o projeto da rede de distribuição de tempo para aproveitar a fonte de tempo privada de alta precisão. A fonte de tempo privada é distribuída por toda a rede privada com os princípios de hierarquia e modularidade descritos nas seções anteriores.
Rede de distribuição de tempo de campus de baixo estrato
Definições de processo
Uma definição de processo é uma série conectada de ações, atividades e alterações executadas por agentes que pretendem atender a uma finalidade ou atingir uma meta. O controle do processo é o processo de planejamento e regulamentação, com o objetivo de executar um processo de forma eficaz e eficiente. Isso é mostrado no próximo diagrama.
Série de processos
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 que determina e relata se o processo é eficaz 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 desse processo é fornecer critérios a serem documentados durante a fase de projeto do NTP e fornecer um recurso de auditoria para uma arquitetura NTP implantada para garantir a conformidade a longo prazo com 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 quantificáveis. Por exemplo, os indicadores de desempenho listados a seguir são numéricos ou medidos por tempo.
-
O tempo necessário para fazer um ciclo por todo o processo.
-
A frequência de execução necessária para detectar proativamente problemas de NTP antes que eles afetem os 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 na solução de problemas ou no diagnóstico de problemas atribuídos a problemas relacionados ao 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 de entradas de processo fornece informações sobre dependências externas. A seguir, é fornecida uma lista de entradas relacionadas ao gerenciamento NTP.
-
Documentação do projeto de NTP
-
Dados de MIB NTP coletados por polling SNMP
Saídas do processo
As saídas do processo são definidas como:
-
Relatórios de configuração NTP definidos na seção Apresentação de dados deste documento
-
Ações corretivas de NTP
Definições de tarefas
As próximas seções definem a inicialização e as tarefas iterativas associadas ao gerenciamento do NTP.
Tarefas de inicialização
As tarefas de inicialização são executadas uma vez durante a implementação do processo e não devem ser executadas durante cada iteração do processo.
Criar o Design do NTP
Quando você verifica as tarefas de pré-requisito, se for determinado que qualquer uma das tarefas não está implementada ou não fornece informações suficientes para atender efetivamente às necessidades desse procedimento, esse fato deverá ser documentado pelo proprietário do processo e submetido ao gerenciamento. A tabela a seguir destaca as tarefas de inicialização de pré-requisitos.
| Tarefa de pré-requisito | Descrição |
|---|---|
| Objetivos da tarefa |
Crie um documento de projeto detalhado para a arquitetura NTP que atenda aos requisitos de projeto e aos objetivos de custo. |
| Entradas da tarefa |
|
| Saída de tarefas |
Documentação do projeto de NTP. |
| Recursos da tarefa |
Arquiteto de engenharia de rede Arquiteto de operações de rede. |
| Funções da tarefa |
Aprovação técnica do projeto de rede pelos revisores de Engenharia e Operações Custos do projeto de rede aprovados pelo gerente de orçamento responsável. |
Criar um arquivo de seed
O processo de gerenciamento NTP requer o uso de um arquivo de seed para eliminar a necessidade de uma função de descoberta de rede. O arquivo de seed registra o conjunto de roteadores que são governados pelo processo NTP e também é usado como um ponto focal para coordenar com os processos de gerenciamento de alterações em uma organização. Por exemplo, se novos nós forem inseridos na rede, eles precisarão 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 próxima tabela descreve como criar um arquivo de seed.
| Tarefa de pré-requisito | Descrição |
|---|---|
| Objetivos da tarefa |
Crie um arquivo de seed que identifique três categorias de dispositivos de rede:
|
| Entradas da tarefa |
Documentação do projeto de NTP Documentação da topologia da rede. |
| Saída de tarefas |
Arquivo de propagação. |
| Recursos da tarefa |
Critérios de projeto que podem ser usados para identificar e priorizar os nós envolvidos na arquitetura NTP. |
Parâmetros de Desempenho NTP de Linha de Base
Vários dos parâmetros disponíveis para monitorar a rede NTP exibem algumas variações normais esperadas. O processo de estabelecimento de uma linha de base é utilizado para caracterizar as variações esperadas normais e para definir limiares que definem condições inesperadas ou anormais. Esta tarefa é usada para estabelecer a linha de base do conjunto variável de parâmetros para a arquitetura NTP. Para obter uma discussão mais detalhada das técnicas de linha de base, consulte o white paper Processo de linha de base: práticas recomendadas.
| Processo | Descrição |
|---|---|
| Objetivos da tarefa |
Parâmetros variáveis da linha de base. |
| Entradas da tarefa |
Identifique os parâmetros variáveis cntpSysRootDelay cntpSysRootDispersion cntpPeersRootDelay cntpPeersRootDispersion cntpPeersOffset cntpPeersDelay cntpPeersDispersion. |
| Saídas de tarefa |
Valores e limites da linha de base. |
| Recursos da tarefa |
Ferramentas que coletam dados SNMP e calculam linhas de base. |
| Função da tarefa |
Engenheiro de rede Engenheiro NMS. |
Tarefas repetidas
As tarefas iterativas são executadas durante cada iteração do processo e sua frequência é determinada e modificada para melhorar os indicadores de desempenho.
Manter o arquivo de propagação
O arquivo de seed é crítico para a implementação eficaz do processo de gerenciamento de NTP. Portanto, o estado atual do arquivo de seed deve ser administrado ativamente. As alterações na rede que afetam o conteúdo do arquivo de seed precisam ser rastreadas pelo proprietário do processo de gerenciamento NTP.
| Processo | Descrição |
|---|---|
| Objetivos da tarefa | Manter precisão do arquivo de seed |
| Entradas da tarefa | Informações sobre alterações na rede |
| Saídas de tarefa | Arquivo de propagação |
| Recursos da tarefa | Relatórios, notificações, reuniões relacionadas a alterações |
| Função da tarefa | Engenheiro de rede Engenheiro NMS |
Executar a verificação de nó NTP
Colete informações sobre varreduras críticas, interessantes e de configuração definidas por este procedimento. Execute essas três verificações em frequências diferentes.
Os nós críticos são dispositivos considerados muito importantes para os pontos de dados de coleta de desempenho. A varredura de nó crítico é executada com frequência, por exemplo, a cada hora ou sob demanda, antes e depois das alterações. Os nós interessantes são dispositivos considerados importantes para a integridade geral da arquitetura NTP, mas que não podem estar na árvore de sincronização de tempo para a coleta de dados críticos de desempenho. Esse relatório é executado periodicamente, por exemplo, diariamente ou mensalmente. O relatório de configuração é um relatório abrangente e com muitos recursos que é usado para caracterizar a configuração de implantação de NTP geral em relação aos registros do projeto. Esse relatório é executado com menos frequência, por exemplo, mensalmente ou trimestralmente. Um ponto importante a ser considerado é que a frequência com que os relatórios são coletados pode ser ajustada com base na estabilidade observada da arquitetura NTP e nas necessidades comerciais.
| Processo | Descrição |
|---|---|
| Objetivo da tarefa | Monitorar arquitetura NTP |
| Entrada de tarefa | Dados do dispositivo de rede |
| Saída de tarefas | Relatórios |
| Recursos da tarefa | Aplicativos de software para coletar dados e produzir relatórios |
| Função da tarefa | Engenheiro de rede |
Revisar os relatórios de nó NTP
Essa tarefa exige que os relatórios críticos, interessantes e de configuração sejam revisados e analisados. Se forem detectados problemas, ações corretivas deverão ser iniciadas.
| Processo | Descrição |
|---|---|
| Entradas da tarefa | Verificar relatórios |
| Saídas de tarefa | Análise de estabilidade Ações corretivas |
| Recursos da tarefa | Acesso a dispositivos de rede para investigação e verificação adicionais |
| Função da tarefa | Engenheiro de rede |
Identificação de dados
Características de dados gerais
A tabela a seguir descreve os dados considerados significativos quando você analisa a arquitetura NTP.
| Dados | Descrição |
|---|---|
| ID dos nós | Um dispositivo com NTP configurado |
| Pares | Os pares configurados para o dispositivo |
| Origem da sincronização | O par selecionado para sincronização |
| dados de configuração de NTP | Parâmetros usados para julgar a consistência do design do NTP |
| dados de qualidade do NTP | Parâmetros usados para caracterizar a qualidade das associações NTP |
Identificação de dados de SNMP
Grupo de sistema MIB Cisco NTP
Os dados SNMP NTP são definidos pelo Cisco-NTP-MIB. Para obter informações atuais sobre as versões que suportam esse MIB, use a ferramenta CCO Feature Navigator e selecione a opção MIB Locator. Essa ferramenta é acessada através da página Ferramentas TAC para Tecnologias de Voz, Telefonia e Mensagens.
O grupo de sistema no MIB Cisco NTP fornece informações para o nó de destino que executa o NTP. O nó de destino é o destino das consultas SNMP.
| Nome do objeto | Descrição do objeto |
|---|---|
| cntpSysStratum | A camada do relógio local. Se o valor for definido como 1, uma referência primária, o procedimento Primary-Clock descrito na Seção 3.4.6, emRFC-1305 é invocado. ::= { cntpSystem 2 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.2 |
| cntpSysPrecision | Inteiro assinado que indica a precisão do relógio do sistema, em segundos, à potência de dois mais próxima. O valor deve ser arredondado para a próxima maior potência de dois. Por exemplo, um relógio de 50 Hz (20 ms) ou de 60 Hz (16,67 ms) de frequência de energia recebe o valor -5 (31,25 ms), enquanto um relógio controlado por cristal de 1000 Hz (1 ms) recebe o valor -9 (1,95 ms). ::= { cntpSystem 3 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.3 |
| cntpSysRootDelay | Um número de ponto fixo assinado que indica o atraso total de ida e volta em segundos para a fonte de referência primária na raiz da sub-rede de sincronização. ::= { cntpSystem 4 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.4 |
| cntpSysRootDispersion | O erro máximo em segundos, relativo à fonte de referência primária na raiz da sub-rede de sincronização. Somente valores positivos maiores que zero são possíveis. ::= { cntpSystem 5 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.4 |
| cntpSysRefTime | A hora local em que o relógio local foi atualizado pela última vez. Se o relógio local nunca tiver sido sincronizado, o valor será zero. ::= { cntpSystem 7 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.7 |
| cntpSysPeer | A origem de sincronização atual que contém o identificador de associação exclusivo cntpPeersAssocId da entrada de mesmo nível correspondente em cntpPeersVarTable do par que atua como a origem de sincronização. Se não houver peer, o valor será zero. ::= { cntpSystem 9 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.9 |
| cntpSysClock | A hora local atual. A hora local é derivada do relógio de hardware da máquina específica e incrementa em intervalos com base no design usado. ::= { cntpSystem 10 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.1.10 |
Grupo de correspondentes do Cisco NTP MIB - Tabela de variáveis de correspondentes
O grupo de correspondentes do MIB do Cisco NTP fornece informações sobre os correspondentes do nó de destino.
| Nome do objeto | Descrição do objeto |
|---|---|
| cntpPeersVarTable | Esta tabela fornece informações sobre os peers com os quais o servidor NTP local tem associações. Os peers também são servidores NTP que são executados em hosts diferentes. Esta é uma tabela de cntpPeersVarEntry ::= { cntpPeers 1 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1 |
| cntpPeersVarEntry | Cada entrada de peers fornece informações de NTP recuperadas de um servidor NTP de peer específico. Cada peer é identificado por um identificador de associação exclusivo. As entradas são criadas automaticamente quando o usuário configura o servidor NTP para ser associado a pares remotos. Da mesma forma, as entradas são excluídas quando o usuário remove a associação de peer do servidor NTP. As entradas também podem ser criadas pela estação de gerenciamento definindo valores para cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode e define o cntpPeersEntryStatus como ativo (1). No mínimo, a estação de gerenciamento precisa definir um valor para cntpPeersPeerAddress para ativar a linha. INDEX { cntpPeersAssocId } ::= { cntpPeersVarTable 1 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1 |
| cntpPeersAssocId | Um valor inteiro maior que zero que identifica exclusivamente um peer ao qual o servidor NTP local está associado. ::= { cntpPeersVarEntry 1 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.1 |
| cntpPeersConfigured | Este é um bit que indica que a associação foi criada a partir de informações de configuração e não deve ser desassociada mesmo se o peer se tornar inalcançável. ::= { cntpPeersVarEntry 2 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.2 |
| cntpPeersPeerAddress | O endereço IP do peer. Quando uma nova associação é criada, um valor para esse objeto deve ser definido antes que a linha seja ativada. ::= { cntpPeersVarEntry 3 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.3 |
| cntpPeersMode | SYNTAX INTEGER { unspecified (0), symmetricActive (1), symmetricPassive (2), client (3), server (4), broadcast (5), reservedControl (6), reservedPrivate (7) } Quando uma nova associação de peer é criada, se nenhum valor for especificado para esse objeto, o padrão será symmetricActive (1). ::= { cntpPeersVarEntry 8 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1 1.1.8 |
| cntpPeersStratum | A camada do relógio par. ::= { cntpPeersVarEntry 9 } identificador de objeto = .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 atraso total de ida e volta em segundos, do peer à fonte de referência primária na raiz da sub-rede de sincronização. ::= { cntpPeersVarEntry 13 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.13 |
| cntpPeersRootDispersion | O erro máximo, em segundos, do relógio do peer em relação à fonte de referência primária na raiz da sub-rede de sincronização. Somente valores positivos maiores que zero são possíveis. ::= { cntpPeersVarEntry 14 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.14 |
| cntpPeersRefTime | A hora local no par quando seu relógio foi atualizado pela última vez. Se o relógio do peer nunca tiver sido sincronizado, o valor será zero. ::= { cntpPeersVarEntry 16 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.16 |
| cntpPeersReach | Um registrador de deslocamento usado para determinar o status de acessibilidade do peer, com bits que entram da extremidade menos significativa (mais à direita). Um peer é considerado alcançável se pelo menos um bit nesse registro for definido como um (o objeto é diferente de zero). Os dados no registrador de turno são preenchidos pelos procedimentos do protocolo NTP. ::= { cntpPeersVarEntry 21 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.21 |
| cntpPeersOffset | O deslocamento estimado do relógio par em relação ao relógio local, em segundos. O host determina o valor desse objeto que usa o algoritmo NTP clock-filter. ::= { cntpPeersVarEntry 23 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.21 |
| cntpPeersDelay | O atraso de ida e volta estimado do relógio do peer em relação ao relógio local no caminho de rede entre eles, em segundos. O host determina o valor desse objeto que usa o algoritmo NTP clock-filter. ::= { cntpPeersVarEntry 24 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.24 |
| cntpPeersDispersion | O erro máximo estimado do relógio par em relação ao relógio local no caminho de rede entre eles, em segundos. O host determina o valor desse objeto que usa o algoritmo NTP clock-filter. ::= { cntpPeersVarEntry 25 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.25 |
Levantamento de dados
Levantamento de dados de SNMP
Todas as informações exigidas por esse procedimento podem ser coletadas por meio de consultas SNMP. Para analisar os dados e produzir os relatórios, é necessário desenvolver scripts personalizados ou programas de software.
Apresentação de dados
Relatório de nó crítico do NTP
Os nós críticos são dispositivos importantes na árvore de sincronização dos pontos de coleta de dados de desempenho selecionados. Se houver um serviço de VoIP de alta receita que seja monitorado e métricas de variação de atraso unidirecional forem coletadas, os nós de origem e destino onde os timestamps são registrados serão considerados nós críticos.
Neste exemplo, o projeto NTP foi estabelecido próximo a um exemplo de hierarquia OSPF. Portanto, os relatórios descritos a seguir são formatados para agrupar os dispositivos NTP pela área OSPF do dispositivo. Nos casos em que um nó tem interfaces em várias áreas, uma decisão deve ser tomada pelo software de geração de relatórios sobre qual área o nó pode ser listado para fins de relatório. Como mencionado anteriormente, o OSPF não é um pré-requisito para o NTP. Ele é usado apenas neste documento como exemplo ilustrativo.
| Área | Dispositivo | Dados do dispositivo | Valor |
|---|---|---|---|
| #n AreaId | #1 DeviceId | cntpSysStratum | |
| cntpSysPrecision | |||
| cntpSysRootDelay | |||
| cntpSysRootDispersion | |||
| cntpSysRefTime | |||
| cntpSysPeer | |||
| cntpSysClock | |||
| #n DeviceId | cntpSysStratum | ||
| cntpSysPrecision | |||
| cntpSysRootDelay | |||
| cntpSysRootDispersion | |||
| cntpSysRefTime | |||
| cntpSysPeer | |||
| cntpSysClock |
Relatório de nó interessante do NTP
O formato do relatório de nó interessante é igual ao formato do relatório de nó crítico. Nós interessantes são nós considerados importantes para a arquitetura geral do NTP, mas que não podem contribuir diretamente para a sincronização de tempo de pontos críticos de monitoramento de desempenho.
Relatório de configuração NTP
O relatório de configuração é um relatório abrangente que coleta informações sobre a arquitetura NTP geral. Este relatório é usado para registrar e verificar a implantação do NTP em relação aos registros do projeto.
| Área | Dispositivo | Correspondente | Dados de Par | Valor |
|---|---|---|---|---|
| #n AreaId | #n DeviceId | #1 PeerId | cntpPeersAssocId | |
| cntpPeersConfigured | ||||
| cntpPeersPeerAddress | ||||
| cntpPeersMode | ||||
| cntpPeersStratum | ||||
| cntpPeersRootDelay | ||||
| cntpPeersRootDispersion | ||||
| cntpPeersRefTime | ||||
| cntpPeersReach | ||||
| cntpPeersOffset | ||||
| cntpPeersDelay | ||||
| cntpPeersDispersion | ||||
| #n PeerId | cntpPeersAssocId | |||
| cntpPeersConfigured | ||||
| cntpPeersPeerAddress | ||||
| cntpPeersMode | ||||
| cntpPeersStratum | ||||
| cntpPeersRootDelay | ||||
| cntpPeersRootDispersion | ||||
| cntpPeersRefTime | ||||
| cntpPeersReach | ||||
| cntpPeersOffset | ||||
| cntpPeersDelay | ||||
| cntpPeersDispersion |
Informações Relacionadas
Histórico de revisões
| Revisão | Data de publicação | Comentários |
|---|---|---|
1.0 |
15-Feb-2002 |
Versão inicial |
Feedback