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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
