07-13-2010 01:08 PM - edited 03-06-2019 12:00 PM
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)
Solved! Go to Solution.
07-13-2010 10:45 PM
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).
07-13-2010 01:43 PM
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
07-13-2010 10:20 PM
It is not enough either. He have ntp access group for serving, that means he need to add ntp access group for peering.
07-13-2010 10:45 PM
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).
07-14-2010 05:07 AM
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
07-14-2010 05:07 AM
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
07-14-2010 05:47 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide