RTBH (Remotely Triggered Black Hole) using Bird
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? r04.border01.labkrk05.fab> show route for 192.168.66.1/32 Executing "/usr/sbin/birdc show route for 192.168.66.1/32" Table master4: 192.168.66.1/32 unicast [fc00:5:1:502::1__r01.stem01.la 09:24:07.174] * (100) [AS4290000010i] via fc00:5:1:502::1 on ae201 unicast [fc00:5:1:503::1__r02.stem01.la 09:24:07.174] (100) [AS4290000010i] via fc00:5:1:503::1 on ae202 unicast [fc00:5:1:504::1__r03.stem01.la 09:24:07.172] (100) [AS4290000010i] via fc00:5:1:504::1 on ae203 r04.border01.labkrk05.fab> show route for 192.168.66.1/32 all 192.168.66.1/32 unicast [fc00:5:1:502::1__r01.stem01.la 09:24:07.174] * (100) [AS4290000010i] via fc00:5:1:502::1 on ae201 Type: BGP univ BGP.origin: IGP BGP.as_path: 4290000004 4290000005 4290000008 4290000010 BGP.next_hop: 23.0.0.255 BGP.local_pref: 100 BGP.community: (65535,666) unicast [fc00:5:1:503::1__r02.stem01.la 09:24:07.174] (100) [AS4290000010i] via fc00:5:1:503::1 on ae202 Type: BGP univ BGP.origin: IGP BGP.as_path: 4290000004 4290000006 4290000008 4290000010 BGP.next_hop: 23.0.0.255 BGP.local_pref: 100 BGP.community: (65535,666) unicast [fc00:5:1:504::1__r03.stem01.la 09:24:07.172] (100) [AS4290000010i] via fc00:5:1:504::1 on ae203 Type: BGP univ BGP.origin: IGP BGP.as_path: 4290000004 4290000007 4290000008 4290000010 BGP.next_hop: 23.0.0.255 BGP.local_pref: 100 BGP.community: (65535,666) Regards, Dariusz
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@crfreenet.org) "To err is human -- to blame it on a computer is even more so."
Hello Ondrej, Thanks for explanation and workaround. It works like expected. Thanks, Dariusz On 3/18/24, 2:31 PM, "Ondrej Zajicek" <santiago@crfreenet.org <mailto:santiago@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@crfreenet.org <mailto:santiago@crfreenet.org>) "To err is human -- to blame it on a computer is even more so."
participants (2)
-
Mazur, Dariusz -
Ondrej Zajicek