Qual classificação de QoS deve ser aplicada ao NTP?

O projeto de rede de referência da solução Enterprise QoS da Cisco sugere classificar o NTP como tráfego de gerenciamento de rede e marcá-lo como CS2:

Ao atender às necessidades de QoS do tráfego de gerenciamento de rede, a Cisco recomenda as seguintes diretrizes:

O tráfego de gerenciamento de rede deve ser marcado como DSCP CS2.

Os aplicativos de gerenciamento de rede devem ser explicitamente protegidos com uma garantia mínima de largura de banda.

O tráfego de gerenciamento de rede é importante para executar análises e tendências de capacidade e solução de problemas. Portanto, você pode provisionar uma fila de largura de banda mínima separada para o tráfego de gerenciamento de rede, que pode incluir SNMP, NTP , Syslog, NFS e outros aplicativos de gerenciamento .

Como o NTP é sensível a tremulação, por que o NTP não é marcado como Encaminhamento expedido e tratado da mesma forma que os dados de voz?

Existe uma razão pela qual não deve ser colocado na mesma fila de baixa latência que a voz?

— Stephen Craven
fonte

Eu não acho que "sensível ao jitter" seja uma caracterização justa do NTP. Isso explica muito, mas acredito que o algoritmo e os intervalos de pesquisa podem lidar com uma certa quantidade de tremulação. Então isso me levaria a pensar que não precisa ser tratado da mesma maneira que a voz. (Eu sei pouco sobre QoS embora.)

— Craig Constantine

@CraigConstantine Isso está correto. Na maioria dos ambientes, desde que você possa obter uma fila para superar o tráfego do BE, provavelmente estará à frente de 95% dos dados.

— Ryan Foley

@CraigConstantine, dê uma olhada no RFP4594 Boa captura Stephen. Eu acho que a Cisco não está em linha com o IETF em um presente ...?

— Ronnie Royston

A Cisco é uma grande empresa com muitos indivíduos / grupos diferentes. Nem todos concordam sempre com o que é melhor. Pessoalmente, acho que a recomendação da IETF é melhor quando se trata de "tempo de alta precisão", mas eu pessoalmente não gostaria que o NTP para o meu equipamento de rede (que geralmente não classificaria como alta precisão) fosse "tempo de relógio de parede" ou DF como o RFC coloca. A recomendação da Cisco parece ser mais "intermediária" e está alinhada com o que eu esperaria que atendesse às necessidades gerais de NTP para equipamentos de rede.

— YLearn

@StevenCraven, para que essa seja uma pergunta respondível, precisamos entender que tipo de requisitos de precisão você tem para o NTP e como ele está sendo usado.

— 9788 Mike Angning

Respostas:

Resposta editada: O NTP deve ser colocado na classe EF (igual aos pacotes de voz em tempo real) de acordo com as Diretrizes de configuração da IETF RFC 4594 para as classes de serviço DiffServ .

5.2 Mapeamento para NTP

A partir dos testes executados, as indicações são de que a distribuição precisa do tempo requer um transporte de variação de atraso de pacotes (jitter) muito baixo. Portanto, sugerimos que as seguintes diretrizes para o Network Time Protocol (NTP) sejam usadas:

o Quando o NTP é usado para fornecer um tempo de alta precisão na rede de um administrador (operadora) ou para usuários / clientes finais, a classe de serviço de telefonia deve ser usada , e pacotes NTP devem ser marcados com o valor EF DSCP.

o Para aplicativos que exigem precisão de tempo "relógio de parede", a classe de serviço Padrão deve ser usada e os pacotes devem ser marcados com DF DSCP.

— Ronnie Royston
fonte

corrigido acima

— Ronnie Royston

O NTP não é particularmente sensível à instabilidade porque usa originatee transmittimestamps para controlar o atraso. O Ntp.org explica em detalhes como ele mantém o atraso sob controle , mas aqui está um trecho:

A sincronização de um cliente com um servidor de rede consiste em várias trocas de pacotes em que cada troca é um par de solicitação e resposta. Ao enviar uma solicitação, o cliente armazena seu próprio tempo (data e hora de origem) no pacote que está sendo enviado. Quando um servidor recebe esse pacote, ele, por sua vez, armazena seu próprio tempo (recebimento de carimbo de data / hora) no pacote, e o pacote será retornado após colocar um carimbo de data / hora de transmissão no pacote. Ao receber a resposta, o destinatário registrará novamente seu próprio tempo de recebimento para estimar o tempo de viagem do pacote. O tempo de viagem (atraso) é estimado em metade do "atraso total menos o tempo de processamento remoto", assumindo atrasos simétricos.

A razão pela qual isso não está na mesma categoria que o controle de rede é porque isso não é diretamente responsável pela operação de roteamento / encaminhamento de pacotes. Todas as coisas na categoria de gerenciamento de rede não são componentes críticos do sistema de rede como um todo. Se você perdeu algum pacote relacionado ao SNMP, syslog ou NTP, provavelmente nem perceberia.

O SNMP simplesmente retransmitiria essas informações, pois são baseadas em TCP. Mesmo que a conexão caísse completamente, nada catastrófico aconteceria; você pode fazer com que um agente snmp não responda e tente novamente. Se você perdesse o tráfego syslog (UDP), simplesmente perderia um bocado de informações de log, que provavelmente ainda estão contidas no buffer ou em um arquivo de log no dispositivo. Como o NTP calcula o atraso com base nos pacotes anteriores, além de contabilizar o erro máximo de deslocamento, você realmente não está enfrentando nenhum problema. Na pior das hipóteses, seu tempo varia em alguns picossegundos ...

Se você perdeu um pacote relacionado ao roteamento, mesmo que por um segundo, pode estar enfrentando o sistema inteiro em queda; tornando qualquer outra marcação inútil. Nesse ponto, o NTP simplesmente ficaria totalmente fora de sincronia e confiaria no código local para manter o tempo.

— Ryan Foley
fonte