Just checked that the iburst rate is one packet every 2 secs for a responding client , total 6 .
16:45:00.115534 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48 16:45:00.206980 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48 16:45:02.122616 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48 16:45:02.295478 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48 16:45:04.115161 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48 16:45:04.202371 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48 16:45:06.115260 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48 16:45:06.202423 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48 16:45:08.115264 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48 16:45:08.201688 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48 16:45:10.115066 IP 209.200.39.7.123 > 129.6.15.30.123: NTPv4, Client, length 48 16:45:10.238195 IP 129.6.15.30.123 > 209.200.39.7.123: NTPv4, Server, length 48 So NIST servers should not refuse access , and this one clearly doesn’t. For a client that is stays in INIT. Requests are sent at minpoll , which in my case is 16 secs. 16:23:21.428877 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:23:37.428912 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:23:53.428827 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:24:09.428838 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:24:25.428832 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:24:41.428875 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:24:57.428801 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 16:25:13.428818 IP 209.200.39.7.123 > 128.138.140.44.123: NTPv4, Client, length 48 So my issue is not with iburst as I do not get ANY packets in response from this server but ntpdate does get a response???? > Le 2 août 2015 à 16:33, Charles Swiger <cswi...@mac.com> a écrit : > > On Aug 2, 2015, at 2:31 AM, Mike Cook <michael.c...@sfr.fr> wrote: >> Can anyone confirm that this is an issue? >> >> I habitually put an burst directive in my ntp.conf server statements. ex: >> >> server 129.6.15.30 noselect iburst minpoll 4 maxpoll 6 >> server 128.138.140.44 noselect iburst minpoll 4 maxpoll 6 >> server 98.175.203.200 noselect iburst minpoll 4 maxpoll 6 >> >> But in the case of these NIST servers, sometimes they never get out of INIT >> state. > > iburst isn't usually a problem, but minpoll 4 / maxpoll 6 would be > considered abusive without prior arrangements. minpoll 6 is the fastest > rate you should query other NTP servers without explicit permission. > > To be more specific, folks who implement per-client firewall rate rules > tend to block clients who exceed ~100 packets per hour. > > > The main point of iburst is to quickly get a downed NTP server back up > and serving valid time. That matters most for isolated stratum-2+ > servers; if you've already got S1 timesources available and multiple > redundant NTP servers locally, using iburst is superfluous. > > Sure, use iburst on one remote server entry if you want and/or against > all of the other NTP peers on your local subnet, but it's not obviously > helpful to use iburst everywhere. > > Regards, > -- > -Chuck "Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité." Benjimin Franklin _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
