 |
 |
On Jun 20, 2019, at 12:31 PM, Mike Horwath <[log in to unmask]> wrote: > > On Thu, Jun 20, 2019 at 11:48:13AM -0500, Andrew Hoyos wrote: >> SIX, as an example, has a blackhole IP address, and the route >> servers matching a blackhole community to set next hop to this to >> sink the traffic on the switch fabric. Perhaps something we should >> look into for MICE. > > A good idea - perahps use a specific community advertisement with > correct next-hop into the ether. > Yes, exactly. Rough logic = route server accepts /32’s from you tagged with 65535:666 route server sets next hop no matching prefixes to 206.108.255.0 206.108.255.0 is a blackhole/null destination on switching fabric, or at least translates to dst-mac-addr that is layer2 acl’d to drop. I’d think a prerequisite for this, however, is getting to a point on the route-servers where we are validating/strict filtering prefixes that folks are sending (via IRR), otherwise, we run the risk of people essentially being able to blackhole others. > You can even automate a few things as well from known blacklists, then > another system to accept new networks to be reviewed then blackholed > for. Sure, essentially what many folks do already internally for RTBH, and signaling to upstream. We utilize Kentik to flip back community tagged routes via BGP to for us for dst ip’s under attack matching certain parameters. We blackhole these on our core routers via the same logic above (match community, set next hop to a IP w/ a discard/null route). In turn, you can community match these and send upstream if your upstreams support a RTBH community as well. — Andrew Hoyos [log in to unmask]