O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve um problema que seja encontrado quando o Cisco Identity Services Engine (ISE) e outro Linux-baseou server não sincroniza com um server do Network Time Protocol (NTP) que fosse instalado em um Microsoft Windows server. Uma solução a este problema é fornecida igualmente.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Depois que você configura o ISE CLI a fim usar o Microsoft Windows server como o NTP, não sincroniza. A configuração de controle do domínio padrão do Microsoft Windows server 2012 é usada (configuração de NTP do padrão). O ISE relata que a fonte local está usada ainda:
ise14/admin# show ntp[an error occurred while processing this directive]
Configured NTP Servers:
10.62.145.72
synchronised to local net at stratum 11
time correct to within 11 ms
polling server every 1024 s
remote refid st t when poll reach delay offset jitter
==============================================================================
*127.127.1.0 .LOCL. 10 l 9 64 377 0.000 0.000 0.000
10.62.145.72 .LOCL. 1 u 226 1024 377 0.896 -3.998 4.130
* Current time source, + Candidate , x False ticker
Warning: Output results may conflict during periods of changing synchronization.
Todos os parâmetros (alcançabilidade, atraso, offset, e tremor) não parecem estar corretos, e lá são nenhuma maneira de pesquisar defeitos a edição do CLI (falha da sincronização de NTP). Para a confirmação da edição, você deve ir ao nível da raiz e usar a ferramenta NTPQ a fim perguntar para mais detalhes o demônio do ntpd:
[root@ise14]# ntpq[an error occurred while processing this directive]
ntpq> associations
ind assID status conf reach auth condition last_event cnt
===========================================================
1 53519 9614 yes yes none sys.peer reachable 1
2 53520 9014 yes yes none reject reachable 1
Como mostrado, há duas associações apresentadas. A associação 53520 é marcada como rejeitado. Estão aqui alguns detalhes adicionais para essa associação:
ntpq> mrv 53520 53520[an error occurred while processing this directive]
assID=53520 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10032.150, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0,
offset=-32.465, delay=0.898, dispersion=30.345, jitter=4.519,
reftime=d96b0358.fe7c815a Tue, Aug 4 2015 11:24:40.994,
org=d96b08ed.829514cf Tue, Aug 4 2015 11:48:29.510,
rec=d96b08ed.8b022d8d Tue, Aug 4 2015 11:48:29.543,
xmt=d96b08ed.8ac74cca Tue, Aug 4 2015 11:48:29.542,
filtdelay= 0.90 1.20 0.95 0.93 0.87 0.89 1.19 0.93,
filtoffset= -32.47 -27.95 -26.50 -34.32 -27.74 -18.14 -22.54 -23.79,
filtdisp= 15.63 30.97 46.32 61.68 77.05 92.44 107.82 115.48
É possível confirmar que este é o servidor de NTP previamente configurado (10.62.145.72) para que a sincronização falha. Também, o parâmetro da dispersão da raiz é grande (acima da Senhora 10,000). Use esta informação a fim confirmar este parâmetro do Microsoft Windows server:
C:\Users\Administrator> w32tm /query /status[an error occurred while processing this directive]
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 04/08/2015 11:15:32
Source: Local CMOS Clock
Poll Interval: 6 (64s)
As capturas de pacote de informação apresentam o pedido que é enviado do ISE, com uma dispersão aceitável da raiz do segundo:
Está aqui a resposta do server, que tem uma dispersão da raiz que seja maior de dez segundos:
Em consequência, isto não é aceitado, que faz com que o ISE deixe cair o pedido e continue com a fonte do horário local.
A dispersão da raiz é um número que indique o erro máximo relativo ao origem da referência principal na raiz da sub-rede de sincronização. É aumentada por cada servidor de NTP. À revelia, o servidor Microsoft ajusta o valor a dez segundos somente em que sua própria fonte do horário local é usada (a fim indicar que não é um origem confiável do tempo). Quando o servidor de NTP de Microsoft é configurado com um NTP externo, este valor está derivado do server e o problema não existe.
Conforme a documentação Microsoft, é possível configurar o valor de LocalRootDispersion no registro. Termine estas etapas a fim configurar o valor de registro:
PS C:\Users\Administrator> Stop-Service w32time[an error occurred while processing this directive]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\LocalClockDispersion[an error occurred while processing this directive]
PS C:\Users\Administrator> Start-Service w32time[an error occurred while processing this directive]
C:\Users\Administrator> w32tm /query /status[an error occurred while processing this directive]
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 0.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 04/08/2015 11:15:32
Source: Local CMOS Clock
Poll Interval: 6 (64s)
A ferramenta ISE NTPQ deve agora relatar um baixo (valor da Senhora 48):
ntpq> mrv 53520 53520[an error occurred while processing this directive]
assID=8400 status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
srcadr=10.62.145.72, srcport=123, dstadr=10.62.145.42, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=48.431, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0, offset=8.206,
delay=0.514, dispersion=21.595, jitter=3.456,
reftime=d96b0c49.2c834d26 Tue, Aug 4 2015 12:02:49.173,
org=d96b175c.d472ead9 Tue, Aug 4 2015 12:50:04.829,
rec=d96b175c.d2bf9803 Tue, Aug 4 2015 12:50:04.823,
xmt=d96b175c.d284b95f Tue, Aug 4 2015 12:50:04.822,
filtdelay= 0.90 0.86 0.51 0.87 0.80 0.82 0.85 0.88,
filtoffset= 7.09 5.23 8.21 6.78 2.73 8.43 1.93 9.67,
filtdisp= 15.63 17.56 19.48 21.39 23.32 25.24 27.18 29.08
Isto permite a sincronização de ocorrer como esperado:
ntpq> associations[an error occurred while processing this directive]
ind assID status conf reach auth condition last_event cnt
===========================================================
1 53519 9014 yes yes none reject reachable 1
2 53520 9614 yes yes none sys.peer reachable 1
Você pode igualmente verificar esta informação do CLI:
ise14/admin# show ntp[an error occurred while processing this directive]
Configured NTP Servers:
10.62.145.72
synchronised to NTP server (10.62.145.72) at stratum 2
time correct to within 80 ms
polling server every 128 s
remote refid st t when poll reach delay offset jitter
==============================================================================
127.127.1.0 .LOCL. 10 l 15 64 377 0.000 0.000 0.000
*10.62.145.72 .LOCL. 1 u 26 128 377 0.514 8.206 3.456
* Current time source, + Candidate , x False ticker
Warning: Output results may conflict during periods of changing synchronization.
Algumas das versões mais velhas do Microsoft Windows server puderam ter ajustes diferentes do padrão NTP. Cisco recomenda que você verifica se estes ajustes são corretos e aceitáveis pelo ISE. Verifique estas configurações de registro:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders[an error occurred while processing this directive]
\NTPServer\Enabled
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters\Type[an error occurred while processing this directive]
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config[an error occurred while processing this directive]
\AnnounceFlags
As edições da sincronização de NTP puderam ser causadas pelo Bug ID 2075424 de VMware (o host de ESXi não sincroniza o tempo com o servidor de NTP).
A edição é resolvida nestas correções de programa: