[j-nsp] Remote Triggered Blackhole

[Daniel Roesen]

On Thu, May 27, 2004 at 05:46:47PM -0700, Pedro Roque Marques wrote:
> What i believe makes sense is for one to configure a forwarding export
> policy that matches on that community and sets the appropriate
> attributes.

Agreed.

> At the moment you can really do a 'next-hop discard' in the
> forwarding-table policy... which would probably be a nice addition.

I guess that should have been s/can/cannot/?

> But you can do something much much nicer... you can tag this routes w/
> a destination-class and the configure a firewall to do accounting,
> sampling and then finally discard these nasty-grams.
> 
> It will give you much better data for diagnostics of how many and what
> kind of packets you are discarding... you can rate limit instead of
> discarding also for instance.

> Yap... it may take a little more time to configure. But its much more
> flexible and one can add additional functionality this way...

Yes, but this this is exactly how bloat is usually being justified. :-)

I'm all for having a good infrastructure to allow easy extending
of things, but if you really just want to achieve a simple thing,
using the simplest possible tool is most often a good idea. It
avoids complexity.

To put it bluntly: setting next-hop to an IP which is statically
routed to dsc/discard/reject is something everybuddy understands
as the concept is known from about everywhere.
Modifying route information on the fly from the RIB to the FIB to
assign destination class, then elsewhere in applied-per-interface
firewall filters matching on destination class to remap to another
routing instance to finally discard it there via a default route to
dsc/discard/reject is NOT something the usual networker regards as
"obvious", but more like throwing HFRs after sparrows. :-)

BTW... using DCU requires firewall filters on all interfaces, right?
As far as I see, it MIGHT be possible to put a generalized, non-
interface-specific filter to the PFE with this one (per RIB):

http://www.juniper.net/techpubs/software/junos/junos63/swconfig63-routing/html/routing-tables-config51.html#1036144

Problem is, that this described filter statement doesn't exist:

[edit]
dr at A1# set routing-options rib inet.0 filter
                                      ^
syntax error.

This is 6.3R1.3.

SHOULD it (if it would exist) do what I guess it does? Apply per-RIB
firewall filters for all packets traversing the PFE? This would be
cool to have indeed, bceause currently you cannot apply more than
a single input and output filter to any given interface... which makes
it impossible to "daisy-chain" generic filters with "interface-specific"
(not as in the JUNOS config statement "interface-specific") filters
as it is possible with routing protocol export/import policy chains.
This means if you want to do the DCU stuff, you'll have to copy all
the DCU processing into any interface-specific filter you do for
specific uses. Administrative nightmare.

This is a problem with filters which always bothered me, no matter
which vendor. Does NOONE like to apply default filters on edge
interfaces, PLUS interface-specific stuff, WITHOUT needing to create
a third new filter which is a merge of the generic one and the
interface-specific bits?

But I'm getting off-topic for this thread... :-)

> To make a long story short... i would prefer to build apps in terms of
> hierarchical building blocks: bgp carries the externally signalled
> community; this is translated into a DCU tag that gets installed into
> routes; then you can instruct the forwarding engine to do just about
> anything based on such tag.
> 
> That is of course just my humble opionion...

Fair enough, and I tend to agree with you. I just see the added
complexity (in logic and config size) for a simple job.

Thanks for your thoughts!


Best regards,
Daniel