Solved: NTP issue

marcelo.fanaia · ‎07-13-2010

Please,

Could anyone explain why 200.160.0.8 is not become the master for my CORE layer? I want to get time from external NTP after I want replicate that for client switches.

ntp logging
ntp clock-period 17179869
ntp access-group serve-only 95
ntp master
ntp update-calendar
ntp peer 200.160.0.8

RIO1SW9446#show ntp associations

      address         ref clock     st when poll reach delay offset    disp
*~127.127.7.1      127.127.7.1       7    49    64 377     0.0    0.00     0.0
~200.160.0.8      0.0.0.0          16   416 1024    0     0.0    0.00 16000.
* master (synced), # master (unsynced), + selected, - candidate, ~ configured

RIO1SW9446#show ntp status
Clock is synchronized, stratum 8, reference is 127.127.7.1
nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18
reference time is CFE743EE.EC992E78 (16:58:38.924 BRA-RJO Tue Jul 13 2010)
clock offset is 0.0000 msec, root delay is 0.00 msec
root dispersion is 0.02 msec, peer dispersion is 0.02 msec

RIO1SW9446#show access-lists 95
Standard IP access list 95
    10 permit 127.127.7.1 (40632 matches)
    20 permit 10.20.0.10
    30 permit 10.20.0.7
    90 permit 200.189.40.8
    80 permit 200.160.0.8 (19 matches)
    40 permit 128.254.241.2 (39414 matches)
    100 permit 200.192.232.8
    50 permit 192.168.111.0, wildcard bits 0.0.0.255 (1088746 matches)
    60 permit 172.30.31.0, wildcard bits 0.0.0.255 (262459 matches)
    70 deny   any log (603905 matches)

Alen Danielyan · ‎07-13-2010

You need:

1. one more access list (96):

permit 200.160.0.8

deny any

and exclude "permit 200.160.0.8" from ACL 95, as it is unnecessary.

2. to change "ntp peer 200.160.0.8" onto

ntp server 200.160.0.8

3. add

ntp access-group peer 96

4. Make sure your device has connection to the server (add a permission for "200.160.0.8 eq ntp" in the ACL on your external interface if necessary).

View solution in original post

Amit Singh · ‎07-13-2010

Yes, because you have a wrong command. Change ntp peer 200.160.0.8 to ntp server 200.160.0.8 and it should work for you.

On your clients you will use the CORE layer IP as the ntp master. You configure "ntp peer command" for NTP HA and want you NTP clients to sync to other clock provider. With NTP peers, one NTP-enabled device does not have authority over the other. With the peering model, each device shares its time information with the other, and each device can also provide time synchronization to the other.

Cheers,

-amit singh

Alen Danielyan · ‎07-13-2010

It is not enough either. He have ntp access group for serving, that means he need to add ntp access group for peering.

Alen Danielyan · ‎07-13-2010

You need:

1. one more access list (96):

permit 200.160.0.8

deny any

and exclude "permit 200.160.0.8" from ACL 95, as it is unnecessary.

2. to change "ntp peer 200.160.0.8" onto

ntp server 200.160.0.8

3. add

ntp access-group peer 96

4. Make sure your device has connection to the server (add a permission for "200.160.0.8 eq ntp" in the ACL on your external interface if necessary).

marcelo.fanaia · ‎07-14-2010

Thanks a lot for your help

It is working very well from my CORE.

      address         ref clock     st when poll reach delay offset    disp
~127.127.7.1      127.127.7.1       7    58    64 377     0.0    0.00     0.0
*~200.160.0.8      200.160.7.186     2     0    64 377    12.0 128567     0.4
* master (synced), # master (unsynced), + selected, - candidate, ~ configured

I understood well about ntp server 200.160.0.8, but Why I need to create a new access-list?

Best Regards

Marcelo Fanaia

Richard Burts · ‎07-14-2010

Alen

It is good to see you using what you learned about NTP through participation in the forum and sharing with other forum participants.

I agree with you that the key issue is that you must use both serve-only and peer access-groups. If you use one kind of ntp access-group then you must use both kinds of access-group if you want the device to sync to an external source and also to provide NTP time to other devices.

While I agree that in this situation it is better to configure ntp server than ntp peer, I do not believe that specifying ntp peer causes the problem. I believe that if the original poster specifies the access-group peer and leaves it as ntp peer that it should work. When you configure ntp peer your device should learn NTP from the specified device, and it also asserts that the other device could learn NTP from your device (which is not the case here).

HTH

Rick

HTH

Rick

Alen Danielyan · ‎07-14-2010

rburts wrote:

Alen

It is good to see you using what you learned about NTP through participation in the forum and sharing with other forum participants.

I just could not pass over.

rburts wrote:

While I agree that in this situation it is better to configure ntp server than ntp peer, I do not believe that specifying ntp peer causes the problem. I believe that if the original poster specifies the access-group peer and leaves it as ntp peer that it should work. When you configure ntp peer your device should learn NTP from the specified device, and it also asserts that the other device could learn NTP from your device (which is not the case here).

HTH

Rick

Sure, it would be just superfluous in this case.