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

[Clarke Morledge]

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