[j-nsp] In Search of the Optimal RE Protect Filter - A Journey

[Stefan Fouant]

Hi Clarke,

Lot's of good insight here.  You've put together some pretty good stuff. 
  Have you thought about putting it on a blog somewhere?

Stefan Fouant
JNCIE-ER, JNCIE-M, JNCIE-SEC, JNCI
Technical Trainer, Juniper Networks
http://www.shortestpathfirst.net
http://www.twitter.com/sfouant

On 8/9/2011 4:25 PM, Clarke Morledge wrote:
> I have posed a number of questions to the mailing list over the past
> couple of months about configuring RE protect filters for the MX
> platform. I'd like to summarize my experiences so that others do not
> have to go through the headaches I've had.
>
> An Introduction: In our campus environment we have been moving towards
> an MX core/distribution infrastructure with EX switches at the access
> level. We have had to slowly do this while keeping our layer2
> connectivity with a legacy vendor switch infrastructure intact.
> Unfortunately, part of the reason we have been wanting to rid our campus
> of the legacy layer2 infrastructure is that it has been prone to
> experience topology failures, even with spanning tree enabled --- with
> limited troubleshooting tools.
>
> Various layer2 "micro loops", as well as other broadcast storm events,
> have sometimes resulted in minor, brief outages in our old
> infrastructure, but when these events get propagated into the MX world,
> it could be disaster. So while security and intentional DoS attacks are
> sufficent reasons for implementing RE filters, if you are concerned
> about braodcast storms in general you might consider what we have learned:
>
>
> 1. In addtion to the security approach, RE filters are important from a
> resource perspective. The big bottleneck we've found with respect to
> resources isn't with the RE itself. During an "attack" on the RE, the
> CPU and memory looks pretty healthy. The issue has more to do with the
> buffering of packets as they enter a PFE destined for the RE. A burst of
> traffic to the RE could trigger tail drops in the queuing before doing
> other forms of harm.
>
>
> 2. Juniper's decision to allow all broadcast/multicast traffic on layer3
> interfaces to go to the RE by default makes the MX platform particularly
> vulnerable to Denial of Service attacks involving broadcast storms,
> particularly for otherwise targeted ip broadcasts; i.e. destined to an
> ip subnet.
>
> If you have a Cisco background, you should be aware of this since the
> 6500/7600 systems do NOT handle directed ip broadcasts in the Supervisor
> by default. In Cisco, you have to flip a flag to force the Sup to handle
> various forms of broadcasts (caveat: ARP is always handled by the Sup,
> from what I have observed).
>
>
> 3. The "targeted broadcast" feature new in 10.2 will help to relieve the
> RE of the burden forwarding directed broadcast without
> necessarily involving the RE:
>
> http://www.juniper.net/techpubs/en_US/junos10.2/information-products/topic-collections/config-guide-network-interfac$
>
>
> Though I should confess that I haven't done much testing with this
> recent feature. So I am not sure if this helps with traffic for the
> local subnet; i.e. ip broadcasts that are not intended to cross a subnet
> boundary.
>
>
>
> 4. If your Juniper gear isn't running highly time-sensitive
> applications, the broadcast issue may not bother you. But if you are
> trying to run something like BFD with the recommended setting of 300 ms
> interval with 3 misses, you might be in trouble.
>
>
> 5. I'll put in another plug for Doug Hanks timely book for Securing the
> Routing Engine. It really helped me this summer to provide an effective
> set of templates for building scalable filters:
>
> http://www.juniper.net/us/en/community/junos/training-certification/day-one/fundamentals-series/securing-routing-engine/
>
>
>
> 6. Doug's book is best geared towards protecting the router from
> malicious, security related activity. Unfortnately, it does not really
> address the broadcast storm issue directly. For example, while you can
> build effective RE filters to protect against excessive ip broadcast
> with either discard actions in your filters or rate limiting policers,
> this will not help with ARP broadcasts.
>
> The best tool to deal with ARP storms is using an ARP policer. Applied
> to a layer3 interface via "family inet", it affords you the protection
> that you need. There is a __default_arp_policer__ (look at "show
> policer" for the output), but the settings appear to be rather relaxed.
> Just be careful not to be overly aggressive and starve the RE of the ARP
> packets it really needs to process.
>
> Unfortunately, you can not set the ARP policer on the loopback
> interfaces themselves. It must be applied to either regular interfaces
> on a PFE and/or an IRBs.
>
>
> 7. If you have multiple routing instances, you will need to be aware of
> how they function with respect to your loopback interfaces. Assuming
> that each routing instance (VRFs, virtual routers) has its own loopback
> address that you have configured, you should know that the loopback
> interface serves as the entry point into the RE, which is where it makes
> sense to apply your RE protect filter on input.
>
> If a packet comes in as an all-ones broadcast (255.255.255.255) or an
> all-zeroes broadcast (0.0.0.0), it will enter the RE via the appropriate
> loopback interface per the appropriate routing instance. IP multicast
> behaves the same.
>
> However, if a packet is an ip directed broadcast packet; i.e. destined
> for the broadcast address of an IP subnet, it does NOT enter the RE via
> the loopback address for the routing instance where it was received.
> Instead, it enters the RE via lo0.0, assuming you have lo0.0 in the
> global routing instance. Tricky. Tricky.
>
>
> Well, I hope this all helps someone. If someone can clarify and/or
> improve on this, please let me know. I had to learn the hard way.
>
>
> Clarke Morledge
> College of William and Mary
> Information Technology - Network Engineering
> Jones Hall (Room 18)
> Williamsburg VA 23187
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp