[c-nsp] BGP blackholling with communites

[David Freedman]

I had assumed that it would bypass the "next-hop-self" action which may
be applied to the peering router's iBGP peers (countering the ability to
propogate the new next-hop around the network), there are some mixed
opinions about whether this should or should not work to do this,
(whether it actually works and is implemented is another matter!)

however its nice to have a determined "origin" attribute anyway :)

Saying that, I do not implement customer blackholing this way as it
becomes complex to maintain seperate filters for both the customer's
normal peering session (following their RIR assigned objects)
and filters to allow the customer to inject /32s from their own space to
be blackholed.

We ask the customer to peer with a seperate "blackhole" device, which
maintains a list of filters allowing the customer to announce /32s out
of their own RIR assigned space (on which we explicitly set the
"no-export" community).

The blackhole device then maintains iBGP sessions with the rest of the
network, but does not set "next-hop-self" inward toward them.

Dave.


Dave.

Gert Doering wrote:
| Hi,
|
| On Mon, Mar 21, 2005 at 09:58:10AM +0000, David Freedman wrote:
|> Don't forget to also "set origin igp" in the route-map.
|
| Why?
|
| gert