[j-nsp] Remote Triggered Blackhole

[Pedro Roque Marques]

Daniel Roesen writes:

> "multihop 1" on the EBGP session is your friend.

> Juniper folks: this is popping up again and again... wouldn't it
> make some sense to make an exception in the on-link test for
> next-hops ultimately resolving to the dsc interface or
> discard/reject targets?

Not imho...

The next-hop to a dsc interface may be how many people are used to
acomplishing this goal but imho its far from being the preferred way
to acomplish this.

What i believe makes sense is for one to configure a forwarding export
policy that matches on that community and sets the appropriate
attributes.

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

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...
which is hard to build on top of hacks like a discard interface.

For instance if tomorrow you decide that you would like to bring all
these packets to a centralized server all you need to do is change the
firewall filter to do a "then next-instance" to some forwarding table
where you have a default to some tunnel or another.

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...

  Pedro.