[c-nsp] Assistance configuring a router to trigger remote blackhole

[Naveen Nathan]

> Glad to hear that you got it working!

Thanks.

> Out of curiosity, would you mind sharing the specific pref list entry
> you ended up using?
> 
> Was it simply 'everything/32'?

Tinkering with the prefix-list at first, got the results I expected.
I was redistributing the static routes to BGP, matching on tag and
applying matched routes with a community string.

However since the newly injected routes weren't advertising to eBGP peers,
I explicitly added the host routes to OUTBOUND prefix-list, and everything
started to work. This lead me to believe that the OUTBOUND route-map that
matches on the community string was ineffective. Also, the administrative
hassle of adding the static route and including it in the prefix-list
I found is unacceptable.

I reverted the configuration and focused my efforts on debugging the
route-map that matched on community string. I realized I missed a crucial
statement, ip community-list ... x:666 permit. After tweaking around I
came up with the following changes to the original configuration that
appears to work properly, and doesn't require any modifications of
the OUTBOUND prefix-list (not shown):

ip community-list standard BLACKHOLE permit 27524:666

route-map OUTBOUND permit 100
 description Deny Null Routes
 match community BLACKHOLE
!
route-map OUTBOUND permit 110
 description Allow internal routes
 match ip address prefix-list OUTBOUND
!
route-map STATIC-TO-BGP permit 50
 description Upstream Blackhole
 match tag 666
 set community [UPSTREAM_AS]:666
!

> Although I have a nice s/RTBH internally, I've never seen/experienced it
> done in conjunction with an outside party before.

I noticed a lot of the docs discuss using RTBH intra-AS, so that edge
routers discard the packets. I come from the opposite side since I've
only worked on smaller networks where there's only one edge that is
single/multi-homed. Large providers such as Level3 usually offer
a blackhole community where you can blackhole routes for blocks that
you advertise.

> I'm paranoid about 'accidentally' advertising 'mistakes' to anyone. My
> instinct would be to configure or append to a pref-list that
> specifically has my_ip_blocks == 32, instead of a blanket allow 32 for all.

I think maintaining the prefix-list and static routes will lead to errors,
so that's why I went w/ the former option of matching on community string.

> If I blackhole/sinkhole an external-to-my-ARIN-block IP that is
> attacking my network, I'm deathly afraid that I may accidentally
> advertise it to a peer. I *never* assume that my upstream is doing
> proper filtering, so I *always* ensure that I can only allow out what I
> should be sending out.
> 
> Is this paranoia too far fetched?

I'm not too experienced with provider mishaps, but I think most providers
esp. in the case of RTBH only allow for routes that belong to your own
blocks. I take for granted that the provider does proper filtering,
especially for the case of RTBH.

Hope the above helps.