Rob wrote:
Martin Burnicki martin.burni...@meinberg.de wrote:
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
Harlan Stenn schrieb:
Sander Smeenk writes:
Quoting Miroslav Lichvar (mlich...@redhat.com):
For IPv6 addresses the refid is defined as first 4 bytes of the
Martin Burnicki writes:
Rob wrote:
When the NTP server puts an IPv6 hash in the refid field, it could set
the upper 4 bits to 1. (so the hex value starts with F)
A valid IPv4 address never has that, so ntpq could print it in hex in
this case, and as a dotted quad in other cases.
This
On Mon, Apr 07, 2014 at 09:28:09AM +0200, Martin Burnicki wrote:
Rob wrote:
When the NTP server puts an IPv6 hash in the refid field, it could set
the upper 4 bits to 1. (so the hex value starts with F)
A valid IPv4 address never has that, so ntpq could print it in hex in
this case, and as a
Miroslav Lichvar writes:
On Mon, Apr 07, 2014 at 09:28:09AM +0200, Martin Burnicki wrote:
Rob wrote:
When the NTP server puts an IPv6 hash in the refid field, it could set
the upper 4 bits to 1. (so the hex value starts with F)
A valid IPv4 address never has that, so ntpq could print it
Rob wrote:
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
Harlan Stenn schrieb:
Sander Smeenk writes:
Quoting Miroslav Lichvar (mlich...@redhat.com):
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252
Harlan Stenn st...@ntp.org wrote:
Sander Smeenk writes:
Quoting Miroslav Lichvar (mlich...@redhat.com):
I guess it could also be a IPv6 ref mangling issue?
That could well be. We use IPv6 where we can.
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the
Martin Burnicki writes:
Harlan Stenn schrieb:
Sander Smeenk writes:
Quoting Miroslav Lichvar (mlich...@redhat.com):
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net)
that is 0xac023551, or 172.2.53.81
Harlan Stenn st...@ntp.org wrote:
Martin Burnicki writes:
Harlan Stenn schrieb:
Sander Smeenk writes:
Quoting Miroslav Lichvar (mlich...@redhat.com):
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net)
Quoting E-Mail Sent to this address will be added to the BlackLists
(Null@BlackList.Anitech-Systems.invalid):
if i check 'ntpq -c lpeers' on one of the three stratum-2 servers i
see an IP-address listed as 'refid' for the 'peer'-entries in my
No, its in ntp{1,2,3}.bit.nl's .conf, or via
On Wed, Apr 02, 2014 at 09:48:26AM +0200, Sander Smeenk wrote:
Quoting E-Mail Sent to this address will be added to the BlackLists
(Null@BlackList.Anitech-Systems.invalid):
I guess it could also be a IPv6 ref mangling issue?
That could well be. We use IPv6 where we can.
But that would
Quoting Miroslav Lichvar (mlich...@redhat.com):
I guess it could also be a IPv6 ref mangling issue?
That could well be. We use IPv6 where we can.
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252 (tt52.ripe.net)
that
Sander Smeenk wrote:
Quoting Miroslav Lichvar (mlich...@redhat.com):
I guess it could also be a IPv6 ref mangling issue?
That could well be. We use IPv6 where we can.
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With 2001:7b8:3:32:213:136:0:252
On 2014-04-02, Sander Smeenk ssme...@freshdot.net wrote:
Quoting Null@BlackList.Anitech-Systems.invalid:
if i check 'ntpq -c lpeers' on one of the three stratum-2 servers i
see an IP-address listed as 'refid' for the 'peer'-entries in my
No, its in ntp{1,2,3}.bit.nl's .conf, or via DHCP
On 2014-04-02, Sander Smeenk ssme...@freshdot.net wrote:
Quoting Miroslav Lichvar (mlich...@redhat.com):
I guess it could also be a IPv6 ref mangling issue?
That could well be. We use IPv6 where we can.
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the
Sander Smeenk writes:
Quoting Miroslav Lichvar (mlich...@redhat.com):
I guess it could also be a IPv6 ref mangling issue?
That could well be. We use IPv6 where we can.
For IPv6 addresses the refid is defined as first 4 bytes of the MD5
sum of the address. With
On 03/31/14 14:44, Sander Smeenk wrote:
Quoting Rob (nom...@example.com):
| root@dns1:~# ntpq -c lpeers
| ===
| *someserver.tld .PPS.
| +someserver2.tld .GPS.
| -someserver3.tld .PPS.
| dns2.dns.dmz.bi 172.2.53.81
| dns3.dns.dmz.bi 172.2.53.81
| +someserver4.tld
Quoting Brian Utterback (brian.utterb...@oracle.com):
I can't find this IP, or any hostname resolving to this IP, in any of
my configs. So i'm inclined to go with David Woolley's comment:
'refids are opaque'. Opaque as that remark may be. ;-))
The IP is coming from somewhere. When David said
On 01/04/14 16:39, Brian Utterback wrote:
When David said they are opaque he means in general.
What I mean by opaque is that you should not make any assumptions other
than that they are an identifier to prevent loops. Another reason why
they would not be an IP address would be if the
Sander Smeenk wrote:
...
if i check 'ntpq -c lpeers' on one of the three stratum-2
servers i see an IP-address listed as 'refid' for the 'peer'-entries
in my configuration. This IP-address is not used in any of my
configurations
...
No, its in ntp{1,2,3}.bit.nl's .conf, or via DHCP
or
Hi,
I'm running four NTP-servers. One has a PPS and is stratum-1, the other
three sync from that one primarily and have a few out-of-band fallback
servers configured. This seems to work fine.
However, if i check 'ntpq -c lpeers' on one of the three stratum-2
servers i see an IP-address listed as
On 31/03/14 16:32, Sander Smeenk wrote:
However, if i check 'ntpq -c lpeers' on one of the three stratum-2
servers i see an IP-address listed as 'refid' for the 'peer'-entries
in my configuration. This IP-address is not used in any of my
configurations, no traffic is flowing to- or from that IP
Sander Smeenk ssme...@freshdot.net wrote:
Hi,
I'm running four NTP-servers. One has a PPS and is stratum-1, the other
three sync from that one primarily and have a few out-of-band fallback
servers configured. This seems to work fine.
However, if i check 'ntpq -c lpeers' on one of the three
Quoting Rob (nom...@example.com):
| root@dns1:~# ntpq -c lpeers
| ===
| *someserver.tld .PPS.
| +someserver2.tld .GPS.
| -someserver3.tld .PPS.
| dns2.dns.dmz.bi 172.2.53.81
| dns3.dns.dmz.bi 172.2.53.81
| +someserver4.tld .PPS.
So in the above, dns2 and
23 matches
Mail list logo
