Protocolo de horário de rede: White Paper de práticas recomendadas

Introduction

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 do tempo de rede, na medida necessária para a análise de desempenho moderna, é um exercício essencial. Dependendo dos modelos de negócios e dos serviços fornecidos, a caracterização do desempenho da rede pode ser considerada um importante diferencial de serviço competitivo. Nesses casos, pode ser feito um grande gasto com a implantação de sistemas de gerenciamento de rede e direcionando recursos de engenharia para a análise dos dados de desempenho coletados. No entanto, se não for dada a devida atenção ao princípio, muitas vezes ignorado, da sincronização temporal, esses esforços podem tornar-se inúteis.

Este documento descreve uma definição hipotética de processo para realizar funções de gerenciamento de rede para o Network Time Protocol (NTP). Pretende-se que este procedimento hipotético seja utilizado como exemplo informativo e personalizado por uma organização para ajudar a cumprir objetivos internos.

As informações fornecidas por este documento são apresentadas em várias seções principais, descritas abaixo.

A seção Terminology fornece definições gerais de termos referentes à sincronização de horários.

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 para a 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 alto nível e redes de distribuição de tempo de campus de baixo nível.

A seção Definições de 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 Task Definitions (Definições de tarefas) fornece definições detalhadas sobre as tarefas do processo. Cada tarefa é descrita em termos de objetivos, entradas de tarefas, 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 o NTP. A identificação de dados considera a fonte da informação. Por exemplo, as informações podem estar 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 Coleta de Dados descreve a coleta 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 coletados por scripts automáticos ou por um usuário que faz login manualmente no sistema para emitir o comando CLI e gravar a saída.

A seção Apresentação de Dados fornece exemplos de formato de relatório de como os dados podem ser apresentados.

Terminology

• Precisão — A proximidade do valor absoluto do relógio ao deslocamento de zero.

• Exato — Quando o deslocamento de um relógio é zero em um momento específico.

• Desvio—A medida na variação do desvio ou a segunda derivação do desvio do relógio em relação ao tempo.

• Resolução conjunta — Ao comparar relógios, esta é a soma das resoluções de C1 e C2. A resolução conjunta indica então um limite inferior conservador na precisão de qualquer intervalo de tempo calculado pela subtração de carimbos de tempo gerados por um relógio dos 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 o tempo relatado por um relógio e o tempo real, conforme definido pelo Tempo Universal Coordenado (UTC). Se o relógio relatar um Tc de tempo e o tempo real 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, ao comparar como dois relógios, C1 e C2, se comparam. 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 no tempo relatada por C2 e C1.

• Resolução — A menor unidade pela qual o tempo de um relógio é 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 esse é o tempo real entre as atualizações.

  Observação: os relógios podem ter resoluções muito boas e ainda ser imprecisos.

• Skew—Uma diferença de frequência do relógio, ou o primeiro derivado de seu deslocamento em relação ao tempo.

• Sincronizar — Quando dois relógios são precisos em relação um ao outro (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 real.

Overview

Visão geral do dispositivo

O centro 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 mantém o controle da data e hora atuais. O relógio do sistema pode ser ajustado de várias fontes e, por sua vez, pode ser usado para distribuir o tempo atual por meio de vários mecanismos para outros sistemas. Alguns roteadores contêm um sistema de calendário alimentado por bateria que controla a data e a hora das reinicializações do sistema e das 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 uma fonte de tempo autoritativa e redistribuído através do NTP se nenhuma outra fonte estiver disponível. Além disso, se o NTP estiver em execução, o calendário poderá ser atualizado periodicamente a partir do NTP, compensando o desvio inerente no horário do calendário. Quando um roteador com um calendário do sistema é inicializado, o relógio do sistema é definido com base no tempo 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 abaixo.

• NTP

• Protocolo de horário de rede simples (SNTP - Simple Network Time Protocol)

• Serviço de tempo do Virtual Integrated Network Service (VINES)

• Configuração manual

Determinados dispositivos Cisco low-end suportam apenas o SNTP. O SNTP é uma versão simplificada do NTP somente para clientes. 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 em 100 milissegundos da hora exata. 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 com comportamento incorreto 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 abaixo.

• NTP

• serviço de tempo VINES

• Comandos do usuário show

• Mensagens de registro e depuração

O relógio do sistema controla o tempo 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 horário de verão para que o horário seja exibido corretamente em relação ao fuso horário local. O relógio do sistema controla se o tempo é autoritativo ou não. Se não for autoritativo, o tempo estará disponível somente para fins de exibição e não será redistribuído.

Visão geral do NTP

O NTP foi projetado para sincronizar o tempo em uma rede de máquinas. O NTP é executado no User Datagram Protocol (UDP), usando a porta 123 como origem e destino, que por sua vez é executada sobre IP. O NTP Versão 3 RFC 1305 é usado para sincronizar a cronometragem 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 sobreposta. Embora vários mestres (servidores primários) 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 autoritativa, como um relógio de rádio ou um relógio atômico conectado a um servidor de tempo. O NTP distribui esse tempo pela rede. Um cliente NTP faz uma transação com seu servidor durante seu intervalo de pesquisa (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 pesquisa. 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 pesquisa do NTP em um roteador.

O NTP usa o conceito de um stratum para descrever quantos saltos de NTP de uma máquina estão de uma fonte de tempo autoritativa. Por exemplo, um servidor de horário da camada 1 tem um relógio de rádio ou atômico diretamente conectado a ele. Em seguida, ele envia seu tempo para um servidor de horário da camada 2 por meio do NTP e assim por diante. Uma máquina que executa o NTP escolhe automaticamente a máquina com o menor número de stratum configurado para se comunicar usando o NTP como sua fonte de tempo. Essa estratégia cria efetivamente uma árvore auto-organizativa de alto-falantes NTP. O NTP executa bem sobre os comprimentos de caminho não determinístico das redes comutadas por pacotes, porque faz estimativas robustas das três variáveis chave a seguir na relação entre um cliente e um servidor de tempo.

• Atraso de rede

• Dispersão de tempo de troca de pacotes—Uma medida de erro de relógio máximo entre os dois hosts.

• Deslocamento do relógio—A correção aplicada ao relógio de um cliente para sincronizá-lo.

A sincronização de clock 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) é rotineiramente alcançada.

O NTP evita sincronizar com uma máquina cujo tempo pode não ser preciso de duas maneiras. Primeiro, o NTP nunca sincroniza com uma máquina que não está sincronizada. Em segundo lugar, o NTP compara o tempo relatado por várias máquinas e não será sincronizado 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) geralmente são configuradas estaticamente. Cada máquina recebe o endereço IP de todas as máquinas com as quais deve formar associações. A manutenção de tempo precisa é possível por meio da troca de mensagens NTP 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 é unidirecional.

O tempo mantido em uma máquina é um recurso crítico e é altamente recomendável usar 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 criptografada.

A implementação do NTP da Cisco suporta o serviço stratum 1 em determinadas versões do software Cisco IOS. Se uma versão suportar o comando ntp refclock, é possível conectar um relógio atômico ou de rádio. Certas versões do Cisco IOS suportam o kit de sincronização de NTP do Trimble Palisade (somente roteadores da série Cisco 7200) ou o dispositivo do sistema de posicionamento global de soluções de telecomunicações (GPS). Se a rede usa os servidores de horário público na Internet e a rede é isolada da Internet, a implementação do 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 a hora usando outros meios. Outras máquinas, então, sincronizam 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 de stratum mais altos, escolhe um dos servidores disponíveis para sincronizar. Isso geralmente vem de entre os servidores de stratum 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 o tempo de cada servidor deve ser visto com uma certa desconfiança. O NTP prefere ter acesso a várias fontes de menor tempo de stratum (pelo menos três), já que pode então aplicar um algoritmo de acordo para detectar insanidade em qualquer um desses itens. Normalmente, quando todos os servidores estão de acordo, o NTP escolhe o melhor servidor em termos de stratum mais baixo, mais próximo (em termos de atraso de rede) e precisão reivindicada. A implicação é que, embora se deva ter como objetivo fornecer a cada cliente três ou mais fontes de tempo de estrato inferior, várias dessas fontes só fornecerão serviço de backup e poderão ter menor qualidade em termos de atraso e estrato da rede. Por exemplo, um peer de mesma camada que recebe tempo de origens de stratum mais baixas que o servidor local não acessa diretamente, também pode fornecer um bom serviço de backup.

O NTP geralmente prefere servidores de camadas inferiores a servidores de camadas superiores, a menos que o tempo do servidor de camadas inferiores seja significativamente diferente. O algoritmo é capaz de detectar quando uma fonte de tempo é provavelmente extremamente imprecisa, ou insana, e impedir a sincronização nesses casos, mesmo que o relógio impreciso esteja em um nível de stratum mais baixo. E nunca sincronizará um dispositivo com outro servidor que não esteja sincronizado.

Para declarar se o servidor é confiável, ele precisa passar em muitas verificações de integridade, como:

• As implementações devem incluir tempos limite de sanidade que impeçam transmissões de interceptação se o programa de monitoramento não renovar essas informações após um longo intervalo.

• Verificações de integridade adicionais 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 passou 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 fonte de referência muda rapidamente devido a grandes atrasos dispersos sob condições de congestionamento severo da rede. Os bits peer.config, peer.authenable e peer.autêntico foram adicionados para controlar recursos especiais e simplificar a configuração.

Se pelo menos uma dessas verificações falhar, o roteador o declarará louco.

Modos de associação

As seções a seguir descrevem os modos de associação usados pelos servidores NTP para associar-se entre si.

• Cliente/Servidor

• Simétrico Ativo/Passivo

• Broadcast

Modo cliente/servidor

Os 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 oferece proteção contra mau funcionamento ou ataques de protocolo.

O modo cliente/servidor é a configuração de Internet mais comum. Ele opera no paradigma RPC (remote-procedure-call, chamada de procedimento remoto) clássico com servidores stateless. Neste 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 medida em que o cliente pesquisa os dados de tempo e autenticação do servidor. Um cliente é configurado no modo cliente usando o comando server e especificando o nome ou o endereço do servidor de nomes de domínio (DNS). O servidor não requer nenhuma configuração anterior.

Em um modelo cliente/servidor comum, um cliente envia uma mensagem NTP para um ou mais servidores e processa as respostas como recebidas. O servidor troca endereços e portas, substitui determinados campos na mensagem, recalcula a soma de verificação e retorna a mensagem imediatamente. As informações incluídas na mensagem NTP permitem que o cliente determine o horário do servidor em relação à hora local e ajuste o relógio local de acordo. Além disso, a mensagem inclui informações para calcular a precisão e confiabilidade esperadas no cronograma, 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, cada um deles operando com três ou mais servidores stratum 1 ou stratum 2 nos modos cliente/servidor, assim como todos os outros membros do grupo em modos simétricos. Isso fornece proteção contra disfunções nas quais um ou mais servidores não operam 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 acidentalmente ou propositalmente tempo incorreto. Nestes casos, é utilizado um procedimento de votação especial para identificar fontes artificiais e descartar os seus dados. Por uma questão 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 caminhos de comunicação entre eles.

Configurar uma associação no modo cliente, normalmente indicada por uma declaração de servidor no arquivo de configuração, indica que se deseja obter tempo do servidor remoto, mas que não se deseja fornecer tempo ao servidor remoto.

Modo simétrico ativo/passivo

O modo ativo/passivo simétrico destina-se a configurações em que um grupo de peers de estrato baixo opera como backups mútuos. 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 pares perder todas as fontes de referência ou simplesmente cessar a operação, os outros peers automaticamente reconfiguram para que os valores de tempo possam fluir dos pares sobreviventes para todos os outros na panelinha. Em alguns contextos, isso é descrito como uma operação push-pull, na medida em que o peer puxa ou empurra o tempo e os valores dependendo da configuração específica.

Configurar uma associação no modo simétrico-ativo, normalmente indicado 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. Esse modo é apropriado em configurações que envolvem vários servidores de tempo redundantes interconectados por diversos caminhos de rede, o que é atualmente o caso da 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 operando como um grupo mutuamente redundante. Nesses modos, os servidores dos membros do grupo organizam os caminhos de sincronização para o desempenho máximo, dependendo do jitter de rede e do atraso de propagação. Se um ou mais membros do grupo falharem, os membros restantes serão automaticamente reconfigurados conforme necessário.

Um peer é configurado no modo ativo simétrico usando o comando peer e especificando o nome DNS ou o endereço do outro peer. O outro peer também é configurado no modo ativo simétrico dessa forma.

Observação: se o outro peer não estiver especificamente configurado dessa forma, uma associação passiva simétrica será ativada quando uma mensagem ativa simétrica for recebida. Como um invasor pode representar um peer ativo simétrico e injetar valores de tempo falsos, o modo simétrico deve sempre ser autenticado.

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 de 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, permitindo que todos os clientes operacionais usem o mesmo arquivo de configuração. O modo de broadcast exige um servidor de broadcast 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 destina-se a configurações que envolvem um ou alguns servidores e uma população de clientes potencialmente grande. Um servidor de broadcast é configurado usando o comando broadcast e um endereço de sub-rede local. Um cliente de broadcast é configurado usando o comando broadcast client, permitindo 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 ser sempre autenticado.

Definindo o segundo salto do NTP

Você pode usar o salto ntp {add | delete} comando para inserir um segundo salto. Há opções para adicionar e excluir segundos de salto. Há duas restrições para que isso ocorra:

• O relógio deve estar em estado de sincronização.

• O comando é aceito apenas no mês anterior ao salto. Não será dado 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 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 três estruturas a seguir estão disponíveis para a arquitetura NTP.

• Estrutura de elementos planos

• Estrutura hierárquica

• Estrutura em estrela

Em uma estrutura de peer linear, todos os roteadores se conectam entre si, com alguns roteadores geograficamente separados configurados para apontar para sistemas externos. A convergência do tempo se torna mais longa com cada novo membro da malha NTP.

Em uma estrutura hierárquica, a hierarquia de roteamento é copiada para a hierarquia do NTP. Os roteadores de núcleo têm uma relação cliente/servidor com fontes de tempo externas, os servidores de horário internos têm uma relação cliente/servidor com os roteadores de núcleo, os roteadores do cliente interno (servidores não de horário) têm uma relação cliente/servidor com os servidores de horário internos e assim por diante na árvore. Essas relações são chamadas de escalas hierárquicas. Uma estrutura hierárquica é a técnica preferida, pois oferece consistência, estabilidade e escalabilidade.

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

Em uma estrutura em estrela, todos os roteadores têm uma relação cliente/servidor com alguns servidores temporais no núcleo. Os servidores de tempo dedicados são o centro da estrela e geralmente são sistemas UNIX sincronizados com fontes de tempo externas ou com 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, fornecendo sincronização para um total de mais de 100.000 clientes e servidores na Internet. As listas de NTP Time Servers públicos são atualizadas com frequência. Há também vários servidores privados primários e secundários normalmente não disponíveis para o público.

Observação: o PIX e o ASA não podem ser configurados como um servidor NTP, mas podem ser configurados como um cliente NTP.

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 diagrama abaixo mostra um gráfico comparativo da precisão relativa das tecnologias atuais.

Até recentemente, o uso de fontes de tempo externas não foi 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 estão se tornando 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 (AS) obtém informações de tempo de três servidores de tempo público. O AS corporativo é mostrado como servidores de horário da área 0 e da área 1. Neste exemplo, a hierarquia do NTP segue a hierarquia do OSPF (Open Shortest Path First). No entanto, o OSPF não é um pré-requisito para o NTP. Ele é usado apenas como 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.

A seguinte é a configuração do Cisco IOS 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 descrevia uma rede de distribuição de tempo da WAN. Esta seção move uma etapa para baixo na hierarquia para discutir a distribuição de tempo em uma rede de campus de alto nível.

A principal diferença ao considerar a distribuição de tempo em uma rede de campus de estrato alto é o uso potencial do modo de associação de broadcast. Como 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. Por conseguinte, a compensação dos custos de manutenção deve ser considerada em função da exatidão das medições de desempenho.

A rede de campus de alto nível, 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 da camada 3 rotulados como CB-1 e CB-2. O componente do servidor, localizado na seção inferior da figura, tem dois roteadores de Camada 3 rotulados SD-1 e SD-2. Os dispositivos restantes no bloco de servidores 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 dl-1 e dl-2. Os dispositivos restantes são switches de Camada 2. Neste bloco de acesso do cliente, o tempo é distribuído usando 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.

A configuração dos dispositivos de distribuição da Camada 3 dl-1 é 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, uma fonte de tempo de GPS ou Cesium é fornecida no data center central para a rede de campus de estrato baixo. Isso provisiona uma fonte de tempo do 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 aos exemplos anteriores. A principal diferença nesse 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 design 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 pela rede privada usando os princípios de hierarquia e modularidade descritos nas seções anteriores.

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.

Gráficamente, isso é 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 critérios a serem documentados durante a fase de projeto do NTP e fornecer um recurso de auditoria para uma arquitetura de NTP implantada, garantindo 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 determináveis. Por exemplo, os indicadores de desempenho listados abaixo 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 processos fornece informações sobre dependências externas. Uma lista de entradas relacionadas ao gerenciamento de NTP é fornecida abaixo.

• documentação de projeto NTP

• Dados MIB NTP coletados por polling SNMP

Saídas do processo

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

• Relatórios de configuração do NTP definidos na seção Apresentação de Dados deste documento

• Ações corretivas de NTP

Definições de tarefas

As seções a seguir 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 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	Criar um documento de projeto detalhado para a arquitetura NTP que atenda aos requisitos do projeto e aos objetivos de custo
Entradas da tarefa	Projetar requisitos técnicos e econômicos Documentação de projeto de rede existente Critérios que definem os aspectos necessários a registrar no projeto para permitir funções de gestão Informações de implantação de aplicativos de TI Requisitos de monitoramento de desempenho
Saída de tarefas	documentação de projeto NTP
Recursos da tarefa	Arquiteto de engenharia de rede Arquiteto de operações de rede
Funções da tarefa	Aprovação técnica de projeto de rede por revisores de engenharia e operações Custos de projeto de rede aprovados pelo gerente de orçamento responsável

Criar um arquivo de seed

O processo de gerenciamento do NTP requer o uso de um arquivo de seed para remover a necessidade de uma função de descoberta de rede. O arquivo seed registra o conjunto de roteadores que são regidos pelo processo NTP e também é usado como um ponto focal para coordenar 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 tabela abaixo resume os processos para criação de um arquivo de seed.

Tarefa de pré-requisito	Descrição
Objetivos da tarefa	Criar arquivo de seed que identifica três categorias de dispositivos de rede Dispositivos críticos—interrogados frequentemente para informações de configuração Dispositivos interessantes—interrogados menos frequentemente Todos os dispositivos habilitados para NTP — pesquisou a quantidade mínima
Entradas da tarefa	Documentação do projeto do NTP Documentação da topologia da rede
Saída de tarefas	Arquivo de sementes
Recursos da tarefa	Critérios de projeto que serão usados para identificar e priorizar os nós envolvidos na arquitetura NTP

Parâmetros de desempenho do 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 linha de base é usado para caracterizar as variações normais esperadas e para definir limiares que definem condições inesperadas ou anormais. Esta tarefa é usada para fazer a linha de base do conjunto de variáveis de parâmetros para a arquitetura NTP. Para uma discussão mais detalhada sobre técnicas de linha de base, consulte o Processo de Linha de Base: White Paper de Melhores Práticas.

Processo	Descrição
Objetivos da tarefa	Parâmetros variáveis da linha de base
Entradas da tarefa	Identificar parâmetros de variáveis cntpSysRootDelay cntpSysRootDispersion cntpPeersRootDelay cntpPeersRootDispersion cntpPeersOffset cntpPeersDelay cntpPeersDispersion
Saídas de tarefa	Valores e limites da linha de base
Recursos da tarefa	Ferramentas para coletar dados SNMP e calcular 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 é essencial para a implementação efetiva do processo de gerenciamento do 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 do NTP.

Processo	Descrição
Objetivos da tarefa	Manter a precisão do arquivo de seed
Entradas da tarefa	Informações sobre alterações na rede
Saídas de tarefa	Arquivo de sementes
Recursos da tarefa	Relatórios, notificações, reuniões sobre alterações
Função da tarefa	Engenheiro de rede Engenheiro NMS

Execute a verificação de nó NTP

Colete informações sobre verificações críticas, interessantes e de configuração definidas por este procedimento. Execute essas três verificações em frequências diferentes.

Nós críticos são dispositivos que são vistos como muito importantes para os pontos de dados de coleta de desempenho. A verificação de nó crítico é executada com frequência, por exemplo, por hora ou por demanda, antes e depois das alterações. Os nós interessantes são dispositivos considerados importantes para a integridade geral da arquitetura do NTP, mas podem não estar na árvore de sincronização de tempo para a coleta de dados de desempenho crítico. 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 geral da implantação do NTP em relação aos registros do projeto. Este 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 das 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ó do NTP

Esta tarefa requer que os relatórios críticos, interessantes e de configuração sejam analisados e analisados. Se forem detectados problemas, devem ser iniciadas ações corretivas.

Processo	Descrição
Entradas da tarefa	Analisar 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 interessantes para a análise da arquitetura NTP.

Dados	Descrição
ID de nós	Um dispositivo com NTP configurado
Pares	Os peers configurados para o dispositivo
Origem da sincronização	O peer selecionado para sincronização
dados de configuração de NTP	Parâmetros usados para julgar a consistência do projeto NTP
dados de qualidade NTP	Parâmetros usados para caracterizar a qualidade das associações NTP

Identificação de dados de SNMP

Grupo de sistemas 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 NTP da Cisco 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	O estrato 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, no RFC-1305 é invocado. ::= { cntpSystem 2 } identificador de objeto = 0.1.3.6.1.4.1.9.9.168.1.1.2
cntpSysPrecision	Número inteiro assinado indicando a precisão do relógio do sistema, em segundos, para a potência mais próxima de dois. O valor deve ser arredondado para a próxima potência maior de dois. Por exemplo, um relógio de frequência de potência de 50 Hz (20 ms) ou 60 Hz (16,67 ms) recebe o valor -5 (31,25 ms), enquanto um relógio de cristal de 1000 Hz (1 ms) recebe o valor -9 (1,95 ms). ::= { cntpSystem 3 } identificador de objeto = 0.1.3.6.1.4.1.9.9.168.1.1.3
cntpSysRootDelay	Um número de ponto fixo assinado indicando o atraso total de round trip em segundos, para a origem de referência primária na raiz da sub-rede de sincronização. ::= { cntpSystem 4 } identificador de objeto = 0.1.3.6.1.4.1.9.9.168.1.1.4
cntpSysRootDispersion	O erro máximo em segundos, relativo à origem de referência primária na raiz da sub-rede de sincronização. Somente valores positivos superiores a zero são possíveis. ::= { cntpSystem 5 } identificador de objeto = 0.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 = 0.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 correspondente no cntpPeersVarTable do peer que atua como a origem de sincronização. Se não houver peer, o valor será zero. ::= { cntpSystem 9 } identificador de objeto = 0.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 dependendo do design usado. ::= { cntpSystem 10 } identificador de objeto = 0.1.3.6.1.4.1.9.9.168.1.1.10

Cisco NTP MIB Peer Group - Tabela de Variáveis de Peers

O grupo de pares da MIB do Cisco NTP fornece informações sobre os pares do nó de destino.

Nome do objeto	Descrição do objeto
cntpPeersVarTable	Esta tabela fornece informações sobre os pares com os quais o servidor NTP local tem associações. Os peers também são servidores NTP em execução 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	A entrada de cada peer 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 aos peers 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 configurando valores para cntpPeersPeerAddress, cntpPeersHostAddress, cntpPeersMode e tornando 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
cntpPeersConfigurado	Este é um bit indicando que a associação foi criada a partir das informações de configuração e não deve ser desassociada mesmo que o peer se torne 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. Ao criar uma nova associação, um valor para este objeto deve ser definido antes que a linha fique ativa. ::= { cntpPeersVarEntry 3 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.3
cntpPeersMode	SYNTAX INTEGER { não especificado (0), symmetricAtive (1), symmetricPassive (2), cliente (3), servidor (4), broadcast (5), reservedControl (6), reservedPrivate (7) } Ao criar uma nova associação de peer, se nenhum valor for especificado para este objeto, ele assumirá como padrão symmetricAtive (1). ::= { cntpPeersVarEntry 8 } identificador de objeto = .1.3.6.1.4.1.9.9.168.1.2.1.1.8
cntpPeersStratum	O estrato do peer clock. ::= { 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 indicando o atraso total de round trip em segundos, do peer à origem 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 peer relativo à origem de referência primária na raiz da sub-rede de sincronização. Somente valores positivos superiores a 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 peer quando seu relógio foi atualizado pela última vez. Se o relógio 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 registro de turno usado para determinar o status de acessibilidade do peer, com os bits entrando da extremidade menos significativa (mais à direita). Um peer é considerado alcançável se pelo menos um bit neste registro for definido como um (o objeto é diferente de zero). Os dados no registro 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 peer em relação ao relógio local, em segundos. O host determina o valor desse objeto usando o algoritmo de filtro de relógio NTP. ::= { 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 peer em relação ao relógio local no caminho de rede entre eles, em segundos. O host determina o valor desse objeto usando o algoritmo de filtro de relógio NTP. ::= { 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 peer em relação ao relógio local no caminho de rede entre eles, em segundos. O host determina o valor desse objeto usando o algoritmo de filtro de relógio NTP. ::= { 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 este procedimento podem ser coletadas por meio de consultas SNMP. Para analisar os dados e produzir os relatórios, scripts personalizados ou programas de software deverão ser desenvolvidos.

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 VoIP de alta receita sendo monitorado e métricas de variação de atraso unidirecional sendo coletadas, os nós de origem e de destino onde os carimbos de data e hora são registrados são considerados nós críticos.

Neste exemplo, o projeto NTP foi estabelecido seguindo um exemplo de hierarquia OSPF. Portanto, os relatórios descritos abaixo são formatados para agrupar os dispositivos NTP de acordo com a á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ório sobre qual área o nó será listado para fins de relatório. Como mencionado anteriormente, o OSPF não é um pré-requisito para o NTP. Ele só é usado neste artigo como exemplo ilustrativo.

Área	Dispositivo	Dados do dispositivo	Valor
ID da área #n	ID do dispositivo nº 1	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		cntpSysRefTime
		cntpSysPeer
		cntpSysClock
	DeviceId #n	cntpSysStratum
		cntpSysPrecision
		cntpSysRootDelay
		cntpSysRootDispersion
		cntpSysRefTime
		cntpSysPeer
		cntpSysClock

Relatório de nó interessante do NTP

O formato do relatório de nó interessante é o mesmo do 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 podem não contribuir diretamente para a sincronização temporal dos 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 geral do NTP. 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 peer	Valor
ID da área #n	DeviceId #n	PeerId nº 1	cntpPeersAssocId
			cntpPeersConfigurado
			cntpPeersPeerAddress
			cntpPeersMode
			cntpPeersStratum
			cntpPeersRootDelay
			cntpPeersRootDispersion
			cntpPeersRefTime
			cntpPeersReach
			cntpPeersOffset
			cntpPeersDelay
			cntpPeersDispersion
		PeerId #n	cntpPeersAssocId
			cntpPeersConfigurado
			cntpPeersPeerAddress
			cntpPeersMode
			cntpPeersStratum
			cntpPeersRootDelay
			cntpPeersRootDispersion
			cntpPeersRefTime
			cntpPeersReach
			cntpPeersOffset
			cntpPeersDelay
			cntpPeersDispersion

Informações Relacionadas

• RFC 1305 Network Time Protocol
• RFC 2330 - Estrutura para métricas de desempenho de IP
• Recursos essenciais do IOS que todos os ISP devem considerar v2.84
• Suporte Técnico - Cisco Systems