So, be careful as the Juniper solution varies depending on the platform involved. Make sure you check your devices. It took a few iterations for us to get the right filters on everything. - Jared On Feb 17, 2014, at 12:26 AM, Yucong Sun <sunyucong@gmail.com> wrote:
Just for the reference, here is a more complete solution for Junos (took me a while searching the web to figure it out), hope it helps someone.
policy-options { prefix-list lo0.0-inet-address { apply-path "interfaces lo0 unit 0 family inet address <*>"; } prefix-list ntp-servers { apply-path "system ntp server <*>"; } }
firewall { family inet { filter lo-filter { term ntp-allow { from { source-prefix-list { ntp-servers; lo0.0-inet-address; } protocol udp; destination-port ntp; } then accept; } term ntp-other-discard { from { protocol udp; destination-port ntp; } then { discard; } } term zz-accept { then accept; } } } }
On Sun, Feb 16, 2014 at 8:42 PM, Mark Tinka <mark.tinka@seacom.mu> wrote:
On Monday, February 17, 2014 06:35:46 AM Lyndon Nerenberg wrote:
I was suggesting it as an alternative to just chopping off NTP at your border. Presumably it would be a one-off thing until Juniper issues a patch.
In Junos, applying the right filters to your router's control plane will fix the issue. You don't need to block NTP in the data plane.
Mark.