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 174.48.156.202.
NTP: sym_passive association is mobilized for 174.48.156.202.

So something was listening and who knows what it was causing as a result.