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 <sunyuc...@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.ti...@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.
>>
