Not quite sure why anyone would have thought this to be a good idea, but at least on NetIron MLXe devices, if you enable NTP to keep your clocks sync’d, server mode NTP is also enabled without it being obvious, on who knows what interfaces. In typical Brocade inconsistency, FastIron SX chassis for example, require an explicit “sntp server-mode…” config directive to accomplish the same.
Anyway, on your MLX’s, this config:
ntp source-interface ethernet 4/22 server 10.0.0.50
results in this setup:
#sh ntp stat Clock is synchronized, stratum 3, reference clock is 10.0.0.50 precision is 2**-16 reference time is D6A7978D.80000000 (14:12:12.628280140 Eastern Thu Feb 13 2014) clock offset is -1.0097 msec, root delay is 54.9917 msec root dispersion is 70.9972 msec, peer dispersion is 35.1140 msec system poll interval is 1024, last clock update was 966 sec ago NTP server mode is enabled, NTP client mode is enabled NTP master mode is disabled, NTP master stratum is 8 NTP is not in panic mode source interface = 4/22
If this is an internet-facing router, this of course results in your routers possibly being amplification points for NTP-based DDoS attacks. You need to add “disable serve” to your NTP config to correct this:
ntp disable serve source-interface ethernet 4/22 server 10.0.0.50
Even if you have your source interface configured on an internal or private network like I have above, the device apparently still listens for NTP connections on its other interfaces, because even before disabling server mode altogether, I noticed this in my logs:
NTP: sym_passive association is demobilized for 188.8.131.52.
NTP: sym_passive association is mobilized for 184.108.40.206.
So something was listening and who knows what it was causing as a result.