NTP - ntpq -c peers showing incorrect stratum for peers
I am running Ubuntu 14.04 as an Amazon Web Services instance.
When I run ntpq -c peers on my server I get the following output:
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
time-a.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
time-b.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
I read this to state that the 2 servers in the response are stratum 16 servers which I know to be incorrect (the nist.gov servers are stratum 1). I know there is a connection to the NIST servers because ntpdate -d time-a.nist.gov connects and shows offset fine.
What causes the stratum to be displayed incorrectly, and what can I do to make sure the command shows the correct stratum?
Thanks
linux ubuntu-14.04 ntp
add a comment |
I am running Ubuntu 14.04 as an Amazon Web Services instance.
When I run ntpq -c peers on my server I get the following output:
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
time-a.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
time-b.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
I read this to state that the 2 servers in the response are stratum 16 servers which I know to be incorrect (the nist.gov servers are stratum 1). I know there is a connection to the NIST servers because ntpdate -d time-a.nist.gov connects and shows offset fine.
What causes the stratum to be displayed incorrectly, and what can I do to make sure the command shows the correct stratum?
Thanks
linux ubuntu-14.04 ntp
add a comment |
I am running Ubuntu 14.04 as an Amazon Web Services instance.
When I run ntpq -c peers on my server I get the following output:
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
time-a.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
time-b.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
I read this to state that the 2 servers in the response are stratum 16 servers which I know to be incorrect (the nist.gov servers are stratum 1). I know there is a connection to the NIST servers because ntpdate -d time-a.nist.gov connects and shows offset fine.
What causes the stratum to be displayed incorrectly, and what can I do to make sure the command shows the correct stratum?
Thanks
linux ubuntu-14.04 ntp
I am running Ubuntu 14.04 as an Amazon Web Services instance.
When I run ntpq -c peers on my server I get the following output:
# ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
time-a.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
time-b.nist.gov .INIT. 16 u - 1024 0 0.000 0.000 0.000
I read this to state that the 2 servers in the response are stratum 16 servers which I know to be incorrect (the nist.gov servers are stratum 1). I know there is a connection to the NIST servers because ntpdate -d time-a.nist.gov connects and shows offset fine.
What causes the stratum to be displayed incorrectly, and what can I do to make sure the command shows the correct stratum?
Thanks
linux ubuntu-14.04 ntp
linux ubuntu-14.04 ntp
edited May 26 '15 at 20:22
Trav
798520
798520
asked May 26 '15 at 19:37
JohnKJohnK
313
313
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
refid .INIT. and stratum 16 indicates that you are not getting any responses from those servers. Check your firewall(s).
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
add a comment |
As already noted stratum 16 servers are unreachable. Therefore, they have no usable time information. As soon as you successfully connect to a server is stratum will be reported. It takes several time exchanges before ntp
will consider using time from the server.
ntpdate -d
uses a non-privileged outgoing port, while ntp
will use port 123 as source and destination. It is possible to block either with firewall rules. If you don't allow established
connections before you block incoming traffic to port 123, ntp
will fail.
It is common to have a cstate RELATED,ESTABLISHED
firewall rule at the top of a chain which accepts traffic. This simplifies the rule set as return traffic does not have be dealt with specific rules.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f919840%2fntp-ntpq-c-peers-showing-incorrect-stratum-for-peers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
refid .INIT. and stratum 16 indicates that you are not getting any responses from those servers. Check your firewall(s).
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
add a comment |
refid .INIT. and stratum 16 indicates that you are not getting any responses from those servers. Check your firewall(s).
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
add a comment |
refid .INIT. and stratum 16 indicates that you are not getting any responses from those servers. Check your firewall(s).
refid .INIT. and stratum 16 indicates that you are not getting any responses from those servers. Check your firewall(s).
answered May 26 '15 at 19:40
hymiehymie
896414
896414
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
add a comment |
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
If ntpq is not getting through the firewall then why does ntpdate -d time.nist.gov give me information?
– JohnK
May 26 '15 at 19:50
add a comment |
As already noted stratum 16 servers are unreachable. Therefore, they have no usable time information. As soon as you successfully connect to a server is stratum will be reported. It takes several time exchanges before ntp
will consider using time from the server.
ntpdate -d
uses a non-privileged outgoing port, while ntp
will use port 123 as source and destination. It is possible to block either with firewall rules. If you don't allow established
connections before you block incoming traffic to port 123, ntp
will fail.
It is common to have a cstate RELATED,ESTABLISHED
firewall rule at the top of a chain which accepts traffic. This simplifies the rule set as return traffic does not have be dealt with specific rules.
add a comment |
As already noted stratum 16 servers are unreachable. Therefore, they have no usable time information. As soon as you successfully connect to a server is stratum will be reported. It takes several time exchanges before ntp
will consider using time from the server.
ntpdate -d
uses a non-privileged outgoing port, while ntp
will use port 123 as source and destination. It is possible to block either with firewall rules. If you don't allow established
connections before you block incoming traffic to port 123, ntp
will fail.
It is common to have a cstate RELATED,ESTABLISHED
firewall rule at the top of a chain which accepts traffic. This simplifies the rule set as return traffic does not have be dealt with specific rules.
add a comment |
As already noted stratum 16 servers are unreachable. Therefore, they have no usable time information. As soon as you successfully connect to a server is stratum will be reported. It takes several time exchanges before ntp
will consider using time from the server.
ntpdate -d
uses a non-privileged outgoing port, while ntp
will use port 123 as source and destination. It is possible to block either with firewall rules. If you don't allow established
connections before you block incoming traffic to port 123, ntp
will fail.
It is common to have a cstate RELATED,ESTABLISHED
firewall rule at the top of a chain which accepts traffic. This simplifies the rule set as return traffic does not have be dealt with specific rules.
As already noted stratum 16 servers are unreachable. Therefore, they have no usable time information. As soon as you successfully connect to a server is stratum will be reported. It takes several time exchanges before ntp
will consider using time from the server.
ntpdate -d
uses a non-privileged outgoing port, while ntp
will use port 123 as source and destination. It is possible to block either with firewall rules. If you don't allow established
connections before you block incoming traffic to port 123, ntp
will fail.
It is common to have a cstate RELATED,ESTABLISHED
firewall rule at the top of a chain which accepts traffic. This simplifies the rule set as return traffic does not have be dealt with specific rules.
edited Jan 23 at 13:28
answered May 27 '15 at 0:57
BillThorBillThor
8,82421718
8,82421718
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f919840%2fntp-ntpq-c-peers-showing-incorrect-stratum-for-peers%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown