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