Re: [ntp:questions] SNTP test bench
Dag-Erling, Yes. The rackety.udel.edu NTP server has KoD enabled and an average headway threshold of 16 s. If you send packets at less than 2-s headway or less tha 16-s average headway, you should get a KoD RATE. If you are not authenticated, pogo.udel.edu should spit KoD AUTH at you. But, note that KoDs themselves are rate limited to no more than two per second. These configurable features are in the current snapshot, so that can do the same things. Dave Dag-Erling Smørgrav wrote: > Does anyone know of a server or piece of software I can use to test an > SNTP implementation - including its handling of KOD packets? > > DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes: > "David L. Mills" <[EMAIL PROTECTED]> writes: > > These configurable features are in the current snapshot, so that can > > do the same things. > I'll set one up locally (inside the firewall) and see if I have better > luck with it than with rackety. Configured my own ntpd with avg 15 min 5, I now get KoDs from 127.0.0.1 as expected. I'd like to say in passing that SNTP is one of the neatest and best- documented network protocols I've ever seen :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
"David L. Mills" <[EMAIL PROTECTED]> writes: > Yes. The rackety.udel.edu NTP server has KoD enabled and an average > headway threshold of 16 s. If you send packets at less than 2-s > headway or less tha 16-s average headway, you should get a KoD > RATE. If you are not authenticated, pogo.udel.edu should spit KoD AUTH > at you. But, note that KoDs themselves are rate limited to no more > than two per second. Hmm, I've been sending requests at one-second intervals without getting KoDs back. It might have something to do with being behind a NAT - perhaps rackety doesn't mind as long each request comes from a different port? > These configurable features are in the current snapshot, so that can > do the same things. I'll set one up locally (inside the firewall) and see if I have better luck with it than with rackety. Thanks for your help, DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
"David L. Mills" <[EMAIL PROTECTED]> writes: > These configurable features are in the current snapshot, so that can > do the same things. One question, what is the range of the "monitor" value on a "discard" line in ntp.conf? My understanding is that if "monitor" is e.g. 10%, it will only send out KoD for 10% of offending requests, is that correct? DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling, Well, there's a reason. In the past serveral days 15 rascals have been punished for rate exceed, one of them continuously at 3 others at 11 and 13 s. The problem is that the rate limit of two KoDs per seconds is itself exceeded and the packet is not sent. The system statistics show a total ove about 1000 packets per hour dropped due rate exceeded of about 3 received packets per hour. If you set up a test locally, include the restrict default limited kod line in the configuration file. Dave Dag-Erling Smørgrav wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > >>Yes. The rackety.udel.edu NTP server has KoD enabled and an average >>headway threshold of 16 s. If you send packets at less than 2-s >>headway or less tha 16-s average headway, you should get a KoD >>RATE. If you are not authenticated, pogo.udel.edu should spit KoD AUTH >>at you. But, note that KoDs themselves are rate limited to no more >>than two per second. > > > Hmm, I've been sending requests at one-second intervals without getting > KoDs back. It might have something to do with being behind a NAT - > perhaps rackety doesn't mind as long each request comes from a different > port? > > >>These configurable features are in the current snapshot, so that can >>do the same things. > > > I'll set one up locally (inside the firewall) and see if I have better > luck with it than with rackety. > > Thanks for your help, > > DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling, The rate violation is caught in the MRU list, which can be retrieved using ntpdc and the monlist command. When the number of clients is small, the list can be retrieved over the net. When the number of clients is larte, like several hundred, there are many UDP packets and one or more are usually dropped. The solution at present is to run ntpdc on the server machine and pipe the monlist output to a local file. Each time a KoD is sent a counter is increased by one. Once each second the counter is decreased by one. If an offending packet arrives and the counter is less than 2, a KoD is sent; otherwise, the packet is dropped without further action. There probably should be some triage, but not without additional complexity. Dave Dag-Erling Smørgrav wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > >>These configurable features are in the current snapshot, so that can >>do the same things. > > > One question, what is the range of the "monitor" value on a "discard" > line in ntp.conf? > > My understanding is that if "monitor" is e.g. 10%, it will only send out > KoD for 10% of offending requests, is that correct? > > DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
"David L. Mills" <[EMAIL PROTECTED]> writes: > The rate violation is caught in the MRU list, which can be retrieved > using ntpdc and the monlist command. When the number of clients is > small, the list can be retrieved over the net. When the number of > clients is larte, like several hundred, there are many UDP packets and > one or more are usually dropped. The solution at present is to run > ntpdc on the server machine and pipe the monlist output to a local > file. > > Each time a KoD is sent a counter is increased by one. Once each > second the counter is decreased by one. If an offending packet arrives > and the counter is less than 2, a KoD is sent; otherwise, the packet > is dropped without further action. There probably should be some > triage, but not without additional complexity. This is both interesting and useful, but begs the question, which was what "monitor" semantics are and how the parameter should be specified (0-1, percentage, whatever) Also, it wouldn't hurt to copy-paste what you wrote above into the doc on udel.edu :) DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
"David L. Mills" <[EMAIL PROTECTED]> writes: > If you set up a test locally, include the > > restrict default limited kod > > line in the configuration file. Yes, that's what I did, and it works beautifully. Thanks! DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNTP test bench
Dag-Erling, The monitor and rate semantics are further elaborated in the recent documentation posted to the web page. Dave Dag-Erling Smørgrav wrote: > "David L. Mills" <[EMAIL PROTECTED]> writes: > >>The rate violation is caught in the MRU list, which can be retrieved >>using ntpdc and the monlist command. When the number of clients is >>small, the list can be retrieved over the net. When the number of >>clients is larte, like several hundred, there are many UDP packets and >>one or more are usually dropped. The solution at present is to run >>ntpdc on the server machine and pipe the monlist output to a local >>file. >> >>Each time a KoD is sent a counter is increased by one. Once each >>second the counter is decreased by one. If an offending packet arrives >>and the counter is less than 2, a KoD is sent; otherwise, the packet >>is dropped without further action. There probably should be some >>triage, but not without additional complexity. > > > This is both interesting and useful, but begs the question, which was > what "monitor" semantics are and how the parameter should be specified > (0-1, percentage, whatever) > > Also, it wouldn't hurt to copy-paste what you wrote above into the > doc on udel.edu :) > > DES ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
