Tag Archives: RE filters

Junos – securing the RE (filter order is important – eBGP running slow?)

First of all – the Juniper Day One books are a superb resource for learning Junos. If you’ve not checked out the library already – do it now! 😉

Recently a client of mine found a bit of a gotcha with the framework filters discussed in the Day One – Securing the Routing Engine (and also the O’Reilly MX book which references the same material).

These books are both great references for deriving a set of RE filters to secure your Junos routers, so I won’t go in to the detail here – just check out the books!

Now on the the gotcha… I’m also mailing a link to this post to the Juniper community folks, so hopefully a revised copy can be linked on the website soon 🙂

UPDATE August 2015: there is now a revised version of the day 1 that mentions the issue discussed in this post and I have also reviewed the O’Reilly MX book and suggested an edit.

The books provide a detailed framework set of filters for protecting the routing engine, allowing you to pick and choose and chain filters as necessary. But if you chain the filters exactly as shown in the example material, you might have some problems. The example material is great, just remember to adapt it to your environment and only include what you need.

Below is an example of the filter order

input-list [ accept-common-services accept-ospf accept-rip accept-bfd accept-bgp accept-ldp accept-rsvp discard-all ];

Filter “accept-common-services” is first in the chain, which essentially references a further set of filters to be checked in order. Let’s take a look at what that is doing. Pretty self explanatory 🙂

filter accept-common-services {
   apply-flags omit;
   term accept-icmp {
      filter accept-icmp;
   }
   term accept-traceroute {
      filter accept-traceroute;
   }
   term accept-ssh {
      filter accept-ssh;
   }
   term accept-snmp {
      filter accept-snmp;
   }
   term accept-ntp {
      filter accept-ntp;
   }
   term accept-web {
      filter accept-web;
   }
   term accept-dns {
      filter accept-dns;
   }
}

The filter we need to look is “accept-traceroute”. In the Day 1, there are terms for UDP, ICMP and TCP, but I’ve only shown the TCP term below.

filter accept-traceroute {
/* omitted text - UDP and ICMP terms */ 
  apply-flags omit;
   term accept-traceroute-tcp {
      from {
         destination-prefix-list {
            router-ipv4;
            router-ipv4-logical-systms;
         }
         protocol tcp;
         ttl 1;
      }
      then {
         policer management-1m;
         count accept-traceroute-tcp;
         accept;
      }
   }
}

Let’s take a look at what this is doing – matching TCP traffic to IPv4 interfaces on the router, with a TTL of 1. If the traffic is matches, then we accept the traffic, count the packets and police to 1Mbps. At first glance this sounds good – traceroute traffic (e.g. tcptraceroute) using TCP is rate limited (the accept-traceroute also does the same for UDP and ICMP).

But what about TCP traffic with a legitimate TTL of 1?

Which routing protocol uses TCP, a TTL of 1 and might send a lot of data – eBGP !

So the unintended effect is if the filters are chained in as shown in the examples, i.e. as below:

[ accept-common-services accept-ospf accept-rip accept-bfd accept-bgp accept-ldp accept-rsvp discard-all ]

then the “accept-bgp” filter will not be matched for eBGP trafic – the “accept-common-services” filter will match eBGP, and eBGP traffic will be rate limited to 1Mbps! Clearly you don’t want this if you are synchronising a full routing table.

The quick way to look for this is to run the command “show firewall filter lo0.0-i”, and look for the counters “accept-traceroute-tcp-lo0.0-i” and the policer “management-1m-accept-traceroute-tcp-lo0.0-i”. If either of these are showing high counter values, then either you are experiencing excessive TCP traceroute, or perhaps you might want to look at the filter order! 🙂

There is a simple fix of course – either put the “accept-bgp” filter first in the chain, or if TCP traceroute isn’t of interest then remove the configuration from the “accept-traceroute” filter.

So if you’ve used these filters as a basis for you own RE filters, it might be worth taking a look at the filter chain order.