NTP BUG

Dear all,
Since Windows 2008 we had a bug with the PDC and ntp service.
Migrated thru R2, 2012 adn now 2012 R2 I must fix this NTP probleme as we have regularly many probleme with the time driffting on the different dc in the domain (dfs sccm abd other services get hit regularly)
I am not able to get the PDC set on a NTP sync, whatever command i try.
At first the PDC wanted to ajust on another secondary dc, after hours of try i finaly reset this situation by getting him (not wanted) to ajust on cmos.
Here si what I last tried:
C:\Users\administrateur>net stop w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.
C:\Users\administrateur> w32tm /unregister
W32Time successfully unregistered.
C:\Users\administrateur> w32tm /register
W32Time successfully registered.
C:\Users\administrateur> net start w32time
The Windows Time service is starting.
The Windows Time service was started successfully.
C:\Users\administrateur> W32tm /config /manualpeerlist:0.ch.pool.ntp.org,0×1 /sy
ncfromflags:manual /reliable:yes /update
The command completed successfully.
C:\Users\administrateur> w32tm /config /update
The command completed successfully.
C:\Users\administrateur>net stop w32time && net start w32time
The Windows Time service is stopping.
The Windows Time service was stopped successfully.
The Windows Time service is starting.
The Windows Time service was started successfully.
C:\Users\administrateur>w32tm /monitor
SRVGEDC01.xxxxx.com[10.0.1.40:123]:
    ICMP: 0ms delay
    NTP: -0.0037015s offset from xxxxDC02.xxxxx.com
        RefID: SRVGEDC02.promar.com [10.0.1.41]
        Stratum: 2
SRVGEDC02.xxxxx.com *** PDC ***[[fe80::857:4810:b9a2:c98c%17]:123]:
    ICMP: 0ms delay
    NTP: +0.0000000s offset from xxxxDC02.xxxxx.com
        RefID: 'LOCL' [0x4C434F4C]
        Stratum: 1
SRVDBDC02.xxxxx.com[10.0.2.41:123]:
    ICMP: 240ms delay
    NTP: -2.3562741s offset from xxxxDC02.xxxxx.com
        RefID: (unspecified / unsynchronized) [0x00000000]
        Stratum: 0
SRVDBDC01.xxxxx.com[10.0.2.40:123]:
    ICMP: 240ms delay
    NTP: -2.3093726s offset from xxxxDC02.xxxxx.com
        RefID: (unspecified / unsynchronized) [0x00000000]
        Stratum: 0
Warning:
Reverse name resolution is best effort. It may not be
correct since RefID field in time packets differs across
NTP implementations and may not be using IP addresses.
C:\Users\administrateur>
The two dbdc have the same problem, cannot get them to sync with the pdc (they are VM NOT sync with the host).
Please asssit asap, I am open and want to get around this.
I also have used Windos time agent v 4.0 that tell me if a ajust manually my PDC that I have about 14 sec delay from 0.ch.pool.ntp.org..... witch is od as the manual time is correct.....
I have also checked the regedit.....
Any ideas!!!!!!!!!!!!!!!!!!!!!!
Thank you all for your help

Hi,
Thanks for posting in the forum.
Based on your description, I understand that the two virtual DC fails to sync time with the physical PDC. If I have misunderstood your question, please do not hesitate to let me know. Regarding
the current issue, I suggest you could refer to the following thread and articles. They may be useful to us.
hyper-v domain controller machines not synchronize time with AD servers
http://social.technet.microsoft.com/Forums/windowsserver/en-US/4624a76d-32f7-4c54-8803-48906e3a2767/hyperv-domain-controller-machines-not-synchronize-time-with-ad-servers?forum=winserverDS
Virtualizing Domain Controllers and the Windows Time Service
http://msmvps.com/blogs/acefekay/archive/2011/08/23/virtualizing-domain-controllers-and-the-windows-time-service.aspx
Hope this helps.
Best Regards,
Andy Qi
Andy Qi
TechNet Community Support

Similar Messages

  • Looking at syslogs messages getting set_rtc_mmss: can't update from x to x - kernel

    Hello,
       Im just looking at the syslogs im getting from the fabrics.
       I noticed alot of warning about :
    %DAEMON-5-SYSTEM_MSG: time reset +0.257072 s - ntpd[5315]
    %KERN-4-SYSTEM_MSG: set_rtc_mmss: can't update from 49 to 0 - kernel
    %KERN-4-SYSTEM_MSG: set_rtc_mmss: nowtime=1339758026, save_control=0x82, save_freq_select=0x72 - kernel
       To me it looks like the kernel complains when the time get updated by NTP. Someone have those entries in logs also?

    Would help to have the version of UCSM you're running.
    There's an open bug on a similar issue: CSCti71838   - %KERN-4-SYSTEM_MSG: set_rtc_mmss: can't update from 52 to 6 - kernel
    It's a general Nexus OS NTP bug, not specific to UCS.  At this stage it appears purely cosmetic and does not affect the system.  The bug is still in the "new" state.  Please monitor the bug toolkit for updates.
    Can you also check that the delta between the UCS current time and NTP server are less than 30min?
    I'd suggest you open a quick TAC case, provide the output and request your case be linked to this bug.  This will increase the priority to have it resolved.
    Regards,
    Robert

  • NTP ACL on IOS-XE (4500-X) bugged?

    Hi,
    for obvious reasons the protection of NTP servers exposed to the Internet is currently getting some reinvestigation. On a fresh 4500-X running IOS-XE 03.04.03.SG (aka 151-2.SG3) I encountered that
    access-list 12 permit x.y.z.123access-list 12 permit a.b.c.123
    access-list 12 deny   any
    ntp access-group peer 12ntp server x.y.z.123
    ntp server a.b.c.123
    will not prevent certain control queries from getting answered by the switch. For instance, ntpq peer list queries (ntpq -p device-ip) from any source still get a reply, even though the deny any ACE counter (and only that) will increment. Legitimate control queries (from the configured sources) will work as well, but increment the appropriate permittive ACE counters. On other switches (non-XE, like 4900M), the exact same configuration works as expected and denies ntpq control queries. Now those queries (there are more than just peer list queries that bypass the ACL on XE, I haven't checked all of them) aren't as dangerous an amplification tool as monlist is, but there still is amplification - and even without amplification, there's at least an information leak, if not a capability for remote control.
    Has anyone else encountered this issue? Is it present in XE generally, or specific to this platform? I don't have much hardware to test against currently
    BTW, the ACL successfully blocks pure time queries, but in the context of NTP amp attacks, they are of least concern.
    BTW^2, adding a pure deny-all ACL to the three other NTP ACL classes makes no difference - they increment counters, but answers still come back.
    TIA,
    Andre.

    I have 6 devices where the ntp access-group is not working:
    5 x ASR1002 - IOS-XE 03.07.03.S 15.2(4)S3
    1 x 4500X-32 - IOS-XE 03.04.02.SG  15.1(2)SG2
    I have a few older ASR1000's running 03.04.05.S IOS-XE 15.1(3)S5, that do not have the problem.
    Open TAC case. No resolution yet.

  • Using a Cisco Switch as the NTP Master time source for a Windows PDC

    Hi all,
    We have a closed network (no connectivity to the internet) and we have a Core router setup as the NTP Master for the rest of the network.
    All network devices are getting the time synced as intended but we are having issues getting the Primary Domain Controller (PDC) registering to it as a valid NTP time source.
    The problem we have is that we are affected by IOS bug CSCed13703 which rejects the PDC as an NTP associated device. Short of changing the IOS on the Router which is the main router feeding 30 other sites I would like to point the PDC at a different switch (an NTP Client switch) as it’s NTP source, rather than it going to the actual NTP Master.
    I have changed the values in the PDC to point to a different switch (3750) that has it’s time synced with the NTP master, but the PDC doesn’t want to know. I assume it will only accept the time from an official NTP Master .
    Could any of you fine people advise if what I am trying to do is possible and if so how I would go about it. I was thinking of setting the 3750 with the NTP Master command also, but I don’t want to confuse the other cisco devices in the network
    Thanks in advance
    David

    Thanks Marvin,
    I can confirm the Stratum on the 3750 is set to 15.  This is due to the NTP Time source being an internal router and not an authoritative time source out on the internet.  When setting the clock and using the NTP Master command on my internal router it sets the Stratum level to 14.
    I have pointed the PDC at the Router (Stratum 14) and it does successfully sync time, but won't trust it as a valid source after the first sync.  Upon reading I believed this to be the IOS bug as the symptoms are identical. Your theory of the PDC requiring a Stratum 2 time source is logical (especially in this scenario) but I have seen them use Stratum 4 before and it worked just fine.
    I guess I could change the Router acting as a time source for the network to be NTP Master 1 which should force Stratum 1 giving the PDC and all other switches pointing to it a Stratumlevel of 2 which would prove it either way.  I don't mind pointing the PDC at the router instead of the switch so long as it gets the time synced and trusts it from that point on.
    I was going to make the 3750 switch an NTP Master for the Network and point the PDC to it (as per my previous post) but I have noticed this morning that the NTP Master command isn't available on the 3750 as it has no hardware clock!
    Are you aware of any other way of forcing the 3750 to become a time source for the PDC without using the NTP Master command?  I have looked at the NTP Peer command and I have ruled this out already and I still need the switch to be a client of the NTP Master Router on the network
    Cheers for getting involved,
    David

  • /var/db/ntp.drift is missing - Ntpd does not create a driftfile

    I cannot get ntp to create and maintain a driftfile.
    Although I will see one show up occasionally, it never gets updated. If I delete it, a new one may show up the next time ntp is run (the existing one that is running will never create a new one), or it might not.
    Help?

    It also says,
    "The frequency file is updated at intervals of an hour or more depending on the measured clock stability."
    I've never seen the file updated once it's made, and sometimes it doesn't get made if it's not there to begin with.
    Also, I've noticed two bugs. One is Apple related -- if the machine goes to sleep, on wake up the clock will be way off, and need a stepping. However, ntpd wants to assume that the entire drift change occured during the last polling interval (generally around 64-4096 seconds), rather than the total time the machine was asleep. Ntpd isn't restarted when the system wakes up and the clock is known to be in error.
    This has been seen since 10.4.3, and is still present in 10.5.5; it causes two clock steps (at least) on wakeup -- one to correct the clock, and give ntpd an inaccurate, high drift value; the second once it has corrected the drift but restepped the clock again.
    In 10.4, ntp was keeping the drift file up to date. (In fairness, I don't recall if I was using the apple ntp, or if I had compiled the tarball. I do know that I had gotten both "burst" and "iburst" to work, and they do NOT both work in 10.5.5. "Burst" definitely is a no-op, and I'm not sure that "iburst" works or not.)
    The second bug is definitely an ntpd bug, but I don't know where to report it. If the "clock out of range" time is more than 900 seconds, the next update automatically sets the clock. Even if the current time interval is more than 900 (eg, 1024 seconds), which means that if the clock is stable enough to get to 1024, then any error automatically alters the clock, without any "Hey, lets wait and see if we get a second sample that's valid".
    Oddly, that bug has caused me problems in two cases: Dialup (file downloads saturate the line), and wireless (intermittent connections make nice random, occasional delays ...)

  • RTMT REPORTING NTP EVENTS

    RTMT is porting the following from my Publisher and both Subscribers.
    At Wed May 28 15:10:11 BST 2014 on node 10.211.7.100; the following SyslogSeverityMatchFound events generated:  SeverityMatch : Critical MatchedEvent : May 28 15:10:04 dbs-cm-donpub01 user 2 ntpRunningStatus.sh: The local NTP client is off by more than the acceptable threshold of 3 seconds from its remote NTP system peer.  The normal remedy is for NTP Watch Dog to automatically restart NTP.  However; an unusual number of automatic NTP restarts have already occurred on this node.  No additional automatic NTP restarts will be done until NTP time synchronization stabilizes. This is likely due to an excessive number of VMware Virtual Machine migrations or Storage VMotions.  Please consult your VMware Infrastructure Support Team. AppID : Cisco Syslog Agent ClusterID :  NodeID : dbs-cm-donpub01  TimeStamp : Wed May 28 15:10:04 BST 2014
    I have run utils ntp restart on each server and still get the same error.
    Any help please?

    First thing is to post the status of the utils ntp status as Brian noted above.  However, there are also a number of NTP-related bugs in CUCM 8.6 and higher.  I have had several customers with similar issues and it is generally been purely cosmetic.  See the following thread, review the bug IDs, and you may consider opening a TAC case as well:
    https://supportforums.cisco.com/discussion/11275801/problem-ntp-after-upgrade-and-install-vmtools
    Be sure to take a look at Aaron Harrison's recommendation as well in that thread.  He always has solid advice in the forum.
    Hailey
    Please rate helpful posts!

  • Windows Server 2012 as NTP Server for Windows Server 2008R2 Domain Controller

    We have one domain with 3 Windows Server 2008R2 DC's. Our Edge router is configured to get the time from the internet, and was our timesource for the PDC emulator. But lately we have migrated our major routers to Cisco IOS15, and now the timeservice on the
    PDCe is unable to fetch the time. This is a known bug, as you can read here:
    http://social.technet.microsoft.com/Forums/ja-JP/b16de048-8642-4799-b85a-ad092e17dd47/windows-server-2012-ntp-version-compatibility
    Now I've found out that Windows Server 2012 does sync with the router. That's our DirSync server, and is in the same VLAN as our DC's. So I thought: I'll set up the Windows Server 2012 as new timeserver, so our PDCe can sync with that server. (Compony
    policy is that DC's don't talk to the internet). Everything seems alright.
    I've set:
    w32tm /config /manualpeerlist:<IP of router>,0x8 /syncfromflags:manual
    w32tm /config /reliable:yes
    Changed the registry with:
    HKLM\SYSTEM\CC\SERVICES\W32TIME\TIMEPROVIDERS\NTPSERVER - Enabled:1
    HKLM\SYSTEM\CC\SERVICES\W32TIME\Config - AnnounceFlags:A
    And stopped and started the W32Time service. I can see that the Windows 2012 server is fetching the correct time, and checked with NBTSTAT -NA that it's listening on port 123.
    But our PDCe doesn't sync. (also changed the config so it has the 2012 server as timesource). Get the EventID 47:
    Time Provider NtpClient: No valid response has been received from manually configured peer <w2012server> after 8 attempts to contact it. This peer will be discarded as a time source and NtpClient will attempt to discover a new peer with this DNS
    name. The error was: The peer is unreachable.
    What more can I try?

    It only shows me the 3 DC's:
    DC04.domain.local *** PDC ***[[::1]:123]:
        ICMP: 0ms delay
        NTP: +0.0000000s offset from DC04.domain.local
            RefID: 'LOCL' [0x4C434F4C]
            Stratum: 1
    DC03.domain.local[10.x.x.x:123]:
        ICMP: 0ms delay
        NTP: -0.0097028s offset from DC04.domain.local
            RefID: DC04.domain.local [10.x.x.x]
            Stratum: 2
    DC05.domain.local[10.x.x.x:123]:
        ICMP: 0ms delay
        NTP: -0.0127883s offset from DC04.domain.local
            RefID: W8D-VW-DC04.domain.local [10.x.x.x]
            Stratum: 2
    Warning:
    Reverse name resolution is best effort. It may not be
    correct since RefID field in time packets differs across
    NTP implementations and may not be using IP addresses.

  • Ntpd[2591]: ntp:frequency error -512 PPM exceeds tolerance 500 PPM

    Following errors are seen on the switches
    October 24, 2011, 11:34:13 AM, hkftshk14sansw01, 10.210.202.47, Message=<189>: 2011
    Oct 24 11:34:12 GMT: ntpd[2591]: ntp:frequency error -512 PPM exceeds tolerance 500 PPM
    October 24, 2011, 11:34:47 AM, hkftshk14sansw01, 10.210.202.47, Message=<189>: 2011
    Oct 24 11:34:46 GMT: last message repeated 2 times
    October 24, 2011, 11:35:52 AM, hkftshk14sansw01, 10.210.202.47, Message=<189>: 2011
    Oct 24 11:35:51 GMT: last message repeated 2 times
    October 24, 2011, 11:35:52 AM, hkftshk14sansw01, 10.210.202.47, Message=<189>: 2011
    Oct 24 11:35:51 GMT: ntpd[2591]: ntp:frequency error -510 PPM exceeds tolerance 500 PPM
    October 24, 2011, 11:36:25 AM, hkftshk14sansw01, 10.210.202.47, Message=<189>: 2011
    Oct 24 11:36:24 GMT: ntpd[2591]: ntp:frequency error -505 PPM exceeds tolerance 500 PPM
    October 24, 2011, 11:56:32 AM, hkftshk14sansw01, 10.210.202.47, Message=<189>: 2011
    Oct 24 11:56:31 GMT: ntpd[2591]: ntp:time reset +0.442609 s
    Did find the time is same on the ntp server and the switch, however found the timezone to be different ( On the server it is HKT & on the switch it is GMT). Is it possible that the  cause of the errors is due the Time Zone?
    NTP server was configured almost 2 months ago, however the errors have appeared suddenly
    Please advise
    Thanks
    Chetan

    Hello Chetan,
    Please check if these messages are shown in the show logging log:
    ntpd[30009]: ntp:time reset +3.141701 s
    ntpd[30009]: ntp:time reset +3.196390 s
    ntpd[30009]: ntp:kernel time sync enabled 0001
    ntpd[30009]: ntp:time reset +3.193518 s
    ntpd[30009]: ntp:time reset +3.161593 s
    ntpd[30009]: ntp:time reset +3.269245 s
    This means that you've hit bug CSCsv11236.  The freq of sysclk is 1333.330000 MHz which should be 1328.1275MHz. I'll save you the math but this works out to about 3.15 seconds per 15 minutes + ntp overhead.
    The solution is simple:  Check you're running
      BIOS:      version 1.0.19
      kickstart: version 5.0(4)
      system:    version 5.0(4)
    and powercycle the entire system.  This should reset the clock speed of the CPU to the correct one.  It might take a few days for NTP to stabilize again.
    hth,
    Kris

  • OEM12c agents high CPU usage alerts fix (leap second Linux kernel bug)

    Just throwing this out here in case anyone else spent the weekend pulling their hair out and hasn't resolved this yet.
    Due to the leap second that occurred at midnight UTC going into July 1st, most of my OEM 12c BP1 agents on Linux servers went haywire, taking up 100%+ CPU on monitored servers. This appears to be due to a bug triggered by the leap second.
    The following seems to fix the issue without requiring a server reboot.
    as root:
    /etc/init.d/ntp stop
    date `date +"%m%d%H%M%C%y.%S"`
    /etc/init.d/ntp start
    as OEM agent user:
    $AGENT_HOME/bin/emctl stop agent ; $AGENT_HOME/bin/emctl start agent
    I didn't discover the fix, but I've confirmed it works.
    Edited by: BrianP on Jul 2, 2012 11:53 AM -- subject changed to note this is a Linux kernel bug, not a Java bug... kernel bug causes software using futexes (like Java) to spin and timeout repeatedly

    See MOS note "Enterprise Manager Management Agent or OMS CPU Use Is Excessive on or around July 1, 2012 [ID 1472651.1]" for more information on this issue. Oracle notes it may occur from versions 10.2.0.5 through 12.1.0.1.0.
    See also "Leap Second Hang - CPU Can Be Seen at 100% [ID 1472421.1]" and bug 14264454.
    Thanks abulloch for getting the note out there!

  • Cisco ISE NTP MD5 hash is 20-Bytes?

    When attempting to configure an NTP authentication-key in the Cisco ISE CLI I noticed that it will not accept an md5 hash of 32 characters (16 bytes). Instead it is expecting a 40 character (20 bytes) hash. That is in line with a SHA-1 hash, not an MD5 hash even though there is no SHA-1 keyword, only an MD5 keyword.
    What's the deal?
    Cisco ISE Version: 1.1.2.145 (Update 3)
    ise/user(config)# ntp authentication-key 75 ?
      md5  MD5 authentication
    ise/user(config)# ntp authentication-key 75 md5 hash ?
      <WORD>  Hashed key for authentication (Max Size - 40)
    ise/user(config)# ntp authentication-key 75 md5 hash 12345678901234567890123456789012
    % ERROR: Bad hashed key.
    ise/user(config)# ntp authentication-key 75 md5 plain test
    ise/user(config)# do show run | i md5
    ntp authentication-key 75 md5 hash 97dc37c94236ec1b4c56871c2e482cbd6f56bd33
    That's not an MD5 hash as it's 40 characters long (20 bytes).

    Hmm, that is an interesting observation. I am guessing that it is a typo and should be "sha-1" because 40 characters is definitely not MD5 :)
    I would suggest you open a case with Cisco TAC and report this. If you get a bug ID or a different answer please let us know. 
    Thank you for rating helpful posts!

  • NTP authentication on 3750

    Hello,
    Trying to apply NTP authentication to 3750 switches (layer-2 WS-C3750-24P switches) but they don't wont to work. Applying the same config to any router or 4500/6500 chassis, and NTP authenticates straight away. NTP without authentication works fine on 3750s as well...
    ntp authentication-key 1 md5 <key>
    ntp authenticate
    ntp trusted-key 1
    ntp server 10.200.11.200 key 1
    Is there additional config required for 3750s? This is across different IOS versions, so doesn't look like a bug...
    Thanks
    Phil

    ah - you have to be careful what order you paste commands in as it removes trusted-key 1 sometimes...

  • NTP on Netra X1

    NTP can't synchronize some of my Netra's X1.
    It seems that there is an hardware problem.
    There is an interesting thread there :
    http://groups.google.com/groups?hl=en&safe=off&ic=1&th=27940abbaaf487f6,13&seekm=9g2tgt%242qk%241%40news.idiom.com#p
    <<The behavior you observe is exactly what happens with the Blade 100 and also with some Ultra 10s. It has nothing to do with NTPv4. There are at least two bug reports to Sun, one of them from here, that point out a 1000-PPM frequency error in the clock frequency of these machines. A patch is apparently in the works, but for now there is nothing we can do about it.>>
    This answer comes from NTP's house, udel.edu.
    Any patches available ? I can't have a DNS primary server which lose 10 seconds/day.
    Someone has run into the same problem ?
    tnx.
    s.

    I'm planning on driving down to the server and simply trying a few things to see if anything looks like its going to work. Is there any way to determine ahead of time if it can be booted from USB, and if not, how would I go about attempting to boot it from a USB drive once I'm there? Something like 'boot /dev/sdb' from the ok prompt in lom? I'm going to take an old IDE CDROM there as well, how would I get it to boot from that?
    At this point its looking like this thing may become a fancy paperweight. I don't understand the design decision to not at least put a CD/DVD ROM in it.

  • Nexus 5000 as NTP client

    We run 6509 core routers as NTP servers to other IOS routers/switches & servers of several OS flavours.
    All good.
    Recently added some Nexus 5000s and cannot get them to lock.
    No firewalls or ACLs in the path
    6509 (1 of 4) state:
    LNPSQ01CORR01>sh ntp ass
          address         ref clock     st  when  poll reach  delay  offset    disp
    + 10.0.1.2         131.188.3.220     2   223  1024  377     0.5   -6.23     0.7
    +~130.149.17.21    .PPS.             1   885  1024  377    33.7   -0.26     0.8
    *~138.96.64.10     .GPS.             1   680  1024  377    22.7   -2.15     1.0
    +~129.6.15.29      .ACTS.            1   720  1024  377    84.9   -3.37     0.6
    +~129.6.15.28      .ACTS.            1   855  1024  377    84.8   -3.30     2.3
    * master (synced), # master (unsynced), + selected, - candidate, ~ configured
    Nexus state:
    BL01R01B10SRVS01# sh ntp peer-status
    Total peers : 4
    * - selected for sync, + -  peer mode(active),
    - - peer mode(passive), = - polled in client mode
        remote               local              st  poll  reach   delay
    =10.0.1.1               10.0.201.11            16   64       0   0.00000
    =10.0.1.2               10.0.201.11            16   64       0   0.00000
    =10.0.1.3               10.0.201.11            16   64       0   0.00000
    =10.0.1.4               10.0.201.11            16   64       0   0.00000
    Nexus config:
    ntp distribute
    ntp server 10.0.1.1
    ntp server 10.0.1.2
    ntp server 10.0.1.3
    ntp server 10.0.1.4
    ntp source 10.0.201.11
    ntp commit
    interface mgmt0
      ip address 10.0.201.11/24
    vrf context management
      ip route 0.0.0.0/0 10.0.201.254
    Reachability to the NTP source...
    BL01R01B10SRVS01# ping 10.0.1.1 vrf management source 10.0.201.11
    PING 10.0.1.1 (10.0.1.1) from 10.0.201.11: 56 data bytes
    64 bytes from 10.0.1.1: icmp_seq=0 ttl=253 time=3.487 ms
    64 bytes from 10.0.1.1: icmp_seq=1 ttl=253 time=4.02 ms
    64 bytes from 10.0.1.1: icmp_seq=2 ttl=253 time=3.959 ms
    64 bytes from 10.0.1.1: icmp_seq=3 ttl=253 time=4.053 ms
    64 bytes from 10.0.1.1: icmp_seq=4 ttl=253 time=4.093 ms
    --- 10.0.1.1 ping statistics ---
    5 packets transmitted, 5 packets received, 0.00% packet loss
    round-trip min/avg/max = 3.487/3.922/4.093 ms
    BL01R01B10SRVS01#
    Are we missing some NTP or managment vrf setup in the Nexus 5Ks??
    Thanks
    Rob Spain
    UK

    I have multiple 5020's, 5548's, and 5596's, and they all experience this same problem. Mind you I run strictly layer 2. I don't even have feature interface-vlan enabled. I tried: "ntp server X.X.X.X use-vrf management" as well as "clock protocol ntpt". These didn't help. 
    I was told by TAC that there is a bug (sorry I do not have the ID), but basically NTP will not work over the management VRF. The only way I got NTP to work, was by enabling the feature interface-vlan, and adding a vlan interface with an IP and retrieving NTP through this interface. 
    I upgraded to 5.2 (1) in hopes that this would fix the issue. but it did not. 

  • StorEdge T3 NTP sync stopped working last weekend (Aug 23 2008)

    We have 3 T3B's, two running 3.1.4 firmware and one running 3.2.2.
    All 3 stopped sync'ing with their NTP server last Saturday (Aug 23 2008).
    I've just upgraded the 3.2.2 one to 3.2.6 and found that it won't sync either.
    I've checked the NTP servers involved; they're fine. I've also pointed one
    T3 to another NTP server and tcpdump shows it not making any NTP queries.
    'ntp stats' comes back with 'No Status yet' after 24 hours of running.
    The older firmware T3's show no successful sync since last Saturday.
    Our network management picked this up when clock drift of the
    T3's started occuring on Saturday, and now 2 of them are upto 10
    seconds out of sync.
    I gather this is a bug triggered by time crossing some value...
    We've not had this problem in the several years we've had these T3's.
    Anybody else seeing this?
    T3B Release 3.2.6 Mon Feb 5 01:00:35 MST 2007 (192.168.131.71)
    Copyright (C) 1997-2006 Sun Microsystems, Inc.
    All Rights Reserved.
    chivas-t3-0:/:<4>date
    Tue Aug 26 01:54:51 GMT 2008
    chivas-t3-0:/:<1>ntp stats
    No Status yet
    chivas-t3-0:/:<2>ntp
    server 192.168.131.113
    poll unicast
    interval 10
    chivas-t3-0:/:<3>set
    bootmode auto
    bootdelay 3
    ip 192.168.131.71
    netmask 255.255.255.0
    gateway 192.168.131.113
    tftphost 0.0.0.0
    tftpfile
    hostname chivas-t3-0
    timezone UTC
    logto *
    loglevel 3
    rarp off
    mac 00:20:f2:00:b7:cb
    T3B Release 3.1.4 Thu Apr 15 18:13:32 PDT 2004 (192.168.131.69)
    Copyright (C) 1997-2003 Sun Microsystems, Inc.
    All Rights Reserved.
    spruce-t3-0:/:<2>date
    Tue Aug 26 02:00:05 UTC 2008
    spruce-t3-0:/:<1>ntp stats
    lastpoll Sat Aug 23 23:05:30 UTC 2008
    server 192.168.131.113
    offset -0.97959533
    status Successfully adjusted the time.
    T3B Release 3.1.4 Thu Apr 15 18:13:32 PDT 2004 (192.168.131.70)
    Copyright (C) 1997-2003 Sun Microsystems, Inc.
    All Rights Reserved.
    spruce-t3-1:/:<1>date
    Tue Aug 26 02:00:16 UTC 2008
    spruce-t3-1:/:<2>ntp stats
    lastpoll Sat Aug 23 22:52:42 UTC 2008
    server 192.168.131.113
    status No adjustment is necessary.

    As strange as the problem started, it also stopped on all 3 T3's at around Sep 6 06:50 UTC (or within 5 mins of this).
    Now all 3 are in sync again, after getting upto 60s out of drift.
    Prior, I ran tcpdump for several days watching for NTP requests from one of the T3's; there were none.
    Now its polling normally (every couple of minutes; I had interval set to 1 on this box).
    So they were not doing NTP requests from Aug 23 22:52 approx to Sep 6 06:50, almost exactly 14 days.
    Very strange.

  • Ntp service depends on dns but is started too soon

    Given servers defined in /etc/inet/ntp.conf, the service starts interactively (svcadm enable ntp) with an initial ntpdate call to set the clock.
    However, this fails on boot up as the servers are not found unless defined in /etc/inet/hosts. As a consequence, there can be a significant initial offset from the RTC, which corrupts the clock drift value and takes hours longer to stabilise.
    This implies that the ntp service is being started too soon before dns whereas it should be started after dns.

    I would check to see if this is still true in the most recent releases of Solaris Express. If it is, you can log a bug about it.
    For your existing machines, you could probably create a dependency on milestone/name-services for the ntp service and see if that fixes it.
    Darren

Maybe you are looking for