Can you post an export rsc to give me a basic BGP setup to drop incoming packets from 10.252.0.7/32?
I'm hoping you can give me a starting point so I can understand how this works.
A few things to note - the implementation is different depending on whether the client and server peer using eBGP or iBGP.
iBGP doesn't need any kind of route filtering at all to distribute a blackhole route IF you have a pre-configured "blackhole" next hop IP (e.g. 169.254.255.254. . .)
This is because iBGP does not modify the "next hop" addresses of prefixes within your AS. So if router1 originates/learns-from-eBGP/redistributes a prefix, with next hop of a.b.c.d, then advertises this prefix to router2, router2 will not install the route using router1 as the next hop - it will install the route with a.b.c.d as the next hop. (recursive lookup)
So if all of your routers are configured with a standard static route:
dst=169.254.255.254/32 type=blackhole
Then all you need to do to blackhole a destination within your AS using iBGP is to inject a route into your BGP table whose next hop is 169.254.255.254.
The filter rules I gave are used when you have an eBGP session - basically, your server would be its own ASN (choose some private ASN)
Then any network that wishes to subscribe to the blacklist will need to use some other ASN than the one you chose. (these can even be public if the remote user has a live ASN)
the server's configuration is a bit different than this script for the clients, but a Mikrotik configured as a "client" would need a configuration basically as follows:
eBGP multihop enabled (your server needs this enabled as well - because by default eBGP only works with directly-connected routers using the IP addresses of their interfaces on that connection - i.e. IP TTL = 1 for eBGP unless you enable multihop)
The config I give here assumes that the client trusts the server not to make mistakes - this is probably not best practice for any operators who wish to run this on a network of much size due to the risk of having something valid get blackholed... but getting started, it's easy to follow along when the configuration is simple.
/ip settings
set rp-filter=strict
/routing bgp instance
set default as=65530 router-id=10.10.10.10
/routing bgp peer
add in-filter=BlackholeDestination multihop=yes name=BlacklistServer1 out-filter=NoRoutes \
remote-address=192.0.2.100 remote-as=65000 ttl=default
/routing filter
add action=accept chain=BlackholeDestination set-type=blackhole
add action=discard chain=NoRoutes
Obviously this is the very most basic minimum to get it working on the client side.
On the server side, you'd want to use the NoRoutes in-filter because you don't want any clients of the list distribution to ever be able to inject anything into the list, accidentally or maliciously.
The server's configuration might be a tad different based on how you wanted to implement it - say as a standalone server whose entire purpose is to publish the blacklist, but not to participate in any global routing. In this case, you could just configure it to redistribute static, and then create a static blackhole route for each blacklist prefix.
Finally, you could use a community ID on the server to make sure that the server will only send stuff that you intended to be black hole routes (i.e. if you use "redistribute static" then EVERY static route's going to get advertised, not just the blackhole routes)
/routing bgp instance
set default as=65000 router-id=192.0.2.100 redistribute-static=yes
/routing bgp peer
add in-filter=NoRoutes multihop=yes name=Client1 out-filter=OnlyRedistributeBlackholes \
remote-address=10.10.10.10 remote-as=65530 ttl=default
/routing filter
add action=discard chain=NoRoutes
add action=accept bgp-communities=65000:666 chain=OnlyBlackholes
add action=discard chain=OnlyBlackholes
To blackhole a prefix on the server, add a static route like this:
/ip route add bgp-communities=65000:666 distance=1 dst-address=172.16.66.0/26 type=blackhole
The "type=blackhole" is not actually important on the server. What IS important is the bgp-communities=65000:666 part, because the out-filter for each peer should be "OnlyRedistributeBlackholes" - which matches routes having this community applied to them.
65000:666 -> 65000 = your server's ASN, and 666 is arbitrary - it's whatever value you want to use to mean "blackhole community" (it's like saying "category 666")
Hope this is enough to get your experiments off the ground.
Before you go production with anyone who's using it in production, you'd probably want to put some sanity filters on your outputs - e.g. if you have a list of "never blackhole these things" - you should make a set of static routes to those blocks but use a different community, such as 65000:777 and insert a rule earlier in the output chain which has action=discard if bgp-communities=65000:777 matches.