Hi,
Agreed,
but when you have >100 peers that is still a fair bit of work.
I know technically
how to do it and am doing this with transits but then there are only seven of
those. It is not a question of how or can, but should / is it valuable /
constructive?
The starting point in the
thought process having just done it for transits was right ok, now how do we
sensibly scale this to apply it at IXes without everyone having to run round
contacting everyone else and to see if there was an easier way of doing
things, hence the suggestion. Plus it keeps things nice a separated,
your IX peering sessions announce just the main prefixes, the session to the
"blackhole reflector" can be in a separate peer-group and you only send the
/32s to the reflector. You don't have to worry about who uses which
communities as each member that chooses to peer with the reflector is able to
apply an inbound routemaps of their own choosing to any prefixes they receive
from this reflector at each individual IX.
Given that an ISP has elected
to Complete the attack on a host that is being DoSed, for whatever reason, and
they have chosen to send blackhole announcements to transit the logical
extension seems to be to automate the sending of them to IXs to try to further
cut down on traffic. This seems like a easy way, internally you just
community tag on the trigger box for where you want the announcement to go,
transit, internal, customers, IX all,1 2 not 3 - whatever - and BGP sends it
out. Easy, and a single system to send out all updates when you choose to and
easy to remove when you want to take it out again.
If you subscribe to
completing the attack as a strategy, then the suggestion seemed like an easy
way of rolling it out to the next logical point after
transit.
Kind
Regards
Ben