Hello Ondrej, Thanks for explanation and workaround. It works like expected.
Thanks, Dariusz On 3/18/24, 2:31 PM, "Ondrej Zajicek" <santi...@crfreenet.org <mailto:santi...@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: santi...@crfreenet.org <mailto:santi...@crfreenet.org>) "To err is human -- to blame it on a computer is even more so."
