4

I'm trying to test behaviour of a server that's configured with a badly behaved NTP server, such as one that's drifting wildly or reporting times that jump around excessively.

I've found lots of advice for setting up a good NTP system, but how can I set up a deliberately bad one?

This question pointed me at ntpdsim, but that tests the behaviour of the ntp client and doesn't seem to touch the system clock, whereas I want to see how my system as a whole behaves when the NTP server is badly behaved.

Community
  • 1
me_and
  • 158
  • 1
  • 9
  • 3
    Don't do this, it isn't a good idea. The correct thing to do with bad NTP servers is to fix them, or turn them off. Provided the clients have a good pool of servers to choose from, [they'll mark such a server as `bad ticker` pretty quickly](http://lists.ntp.org/pipermail/questions/2015-February/040154.html), anyhow. – MadHatter Apr 20 '16 at 13:34
  • 3
    @MadHatter One does not rule out the other. It is entirely appropriate to test how a system behaves when given bad input. Whose responsibility it is to test it can be discussed. But putting a system in production without ever having tested how it responds to bad input is not a good idea. – kasperd Apr 20 '16 at 13:40
  • 1
    `ntpd` has already been pretty extensively tested as to how it reacts under such circumstances, when properly configured and resourced, and we know: it identifies the false clock, and ignores it. You only need to test again if you're trying to do something pathologically foolish with your NTP setup. My fear is that the OP is doing exactly that. If so, then his/her effort - not to mention mine - would be much better spent in improving his/her NTP infrastructure so that `ntpd` can do what we know it's capable of. – MadHatter Apr 20 '16 at 13:43
  • @MadHatter And how would you then test if `ntpd` has been configured correctly? – kasperd Apr 20 '16 at 13:49
  • @kasperd does it have a good pool of reachable, independent servers? That's what it needs. With that, it can survive most things; without it, it's quite likely not to work. – MadHatter Apr 20 '16 at 19:45
  • @MadHatter What you are saying sounds an awful lot like suggesting that it's better to trust what one reads on the internet than to test for yourself to be sure. – kasperd Apr 20 '16 at 20:05
  • @kasperd we seem to be having a philosophical discussion, and I don't think this is the place for it. I'm happy about ntpd's tolerance of bad NTP servers. I don't think the OP should make a bad ntp server. If you think (s)he should, why not write an answer saying how to do it, instead of trying to convince me? – MadHatter Apr 20 '16 at 20:09
  • 1
    @me_and Actually it seems to me that ntpdsim might just be what you want. Can you specify in what regard it does not satisfy your demands? – M. Glatki Apr 20 '16 at 21:07
  • `ntpdsim` tests the behaviour of `ntpd` itself. I want to test the behaviour of _other_ software running on a server where `ntpd` doesn't have a reliable clock source. I know from past experience that the software in question doesn't always behave well in that circumstance, but fixing that would be much easier if I could reproduce the scenario in my test lab. – me_and Apr 21 '16 at 15:00
  • I really thing the OP has a valid requirement. Even though you have an ASSUMPTION of how your current ntp configuration behaves (eg multiple server to ensure on e bad wont matter, having a max offset that is tolerated as skew before time is discarded), it is always valuable to actually test your current configuration against the target scenarios. Thumbs up for not being lazy and actually doing this! I am on the same quest right now after burning my fingers on a bad configuration setup. – Stephan Møller Apr 25 '23 at 12:19

1 Answers1

1

For the correct way to do it, configure your NTP servers to four or more different (pool) public peers plus a pair of local GPS appliances. Poorly behaving outliers will be discarded.

Contrast to a wrong way to do it, configuring an undisciplined local clock. You can see how much it drifts without help, probably quite a bit over a few days. It will be discarded as the poorest performing. Then remove this configuration after the experiment, it is not recommended.

John Mahowald
  • 32,050
  • 2
  • 19
  • 34
  • Thing is, I don't want the poorly behaving outliers to be discarded, I want poorly behaving outliers to be the only servers available. Just configuring the server to use the undisciplined local clock isn't going to cause `ntpd` to see its clock sources jumping around or having an infeasibly large drift. – me_and Apr 21 '16 at 15:04
  • If the goal is to see a host with the wrong time just set the time. A few seconds off, several hours to simulate time zones gone wrong, or what have you. Any sane NTP configuration will not behave like that, so maybe do not bother unless you are trying to break ntpd itself. – John Mahowald Apr 22 '16 at 02:53