RTBH (Remotely Triggered Black Hole) using Bird

[Mazur, Dariusz]

Hello Ondrej,
Thanks for explanation and workaround. It works like expected.

Thanks,
Dariusz

On 3/18/24, 2:31 PM, "Ondrej Zajicek" <santiago at crfreenet.org <mailto:santiago at crfreenet.org>> wrote:


On Mon, Mar 18, 2024 at 09:57:22AM +0000, Mazur, Dariusz via Bird-users wrote:
> Hello Bird Users,
> I am trying to implement RTBH (Remotely Triggered Black Hole) in below setup:
> 
> 0.Simplified Topology:
> 
> * ebgp fabric
> * inside fabric we use only IPv6, so we announce IPv4 blocks with IPv6 next hop (extended next hop)
> * tor --- leaf --- spine---3xstem(3xborder_leaf) --- border
> * tor announces 192.168.66.1/32 tagged with (65535,666) up to border
> 
> 1.Border has static route:
> r04.border01.labkrk05.fab> show route for 23.0.0.255
> 23.0.0.255/32 blackhole [DISCARD_ROUTE_v4 2024-01-08] * (200)
> 
> 2.Border learns 192.168.66.1/32. In import filter I change next hop to 23.0.0.255 to blackhole traffic to 192.168.66.1/32.
> I don’t see this change in “show route” but I see this in “show route all”
> 
> Can you give me a tip how to change eBGP next hop in this scenario and resolve it recursively via static route?


Hello


In BIRD, there is BGP Next Hop attribute (bgp_next_hop) and immediate
next hop (gw). In case of non-recursive next hop processing (like from
EBGP), gw is initialized from bgp_next_hop by BGP, but further changes to
the bgp_next_hop (in BGP import filter) does not change gw.


In recursive next hop processing, there is also an indirect next hop that
is initialized from bgp_next_hop by BGP and it is used for route table
lookups to compute gw. As in the non-recursive case, further changes to
the bgp_next_hop does not change the indirect next hop. And this indirect
next hop is not accessible from filters.


In your case i would suggest to avoid indirect resolving through the
blackhole route and instead to change received RTBH routes directly to
blackhole routes:


if ... then
dest = RTD_BLACKHOLE;


-- 
Elen sila lumenn' omentielvo


Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org <mailto:santiago at crfreenet.org>)
"To err is human -- to blame it on a computer is even more so."