BGP - RTBH (inaccessible route)

[yrkkmg7979]

Hello guys,

I'm doing Remote Triggered Blackhole routing Lab, but not working properly. Please help.

• Fact 1: customer is sending 123.1.1.11 with community 11:666 as below. However, ip route for 123.1.1.11 is not installed on the routing table because "inaccessible" issue.

11-1-1#sh ip bgp 123.1.1.11
BGP routing table entry for 123.1.1.11/32, version 47
Paths: (1 available, no best path)
Not advertised to any peer
123, (received & used)
100.100.100.100 (inaccessible) from 11.123.1.2 (123.1.0.1)
Origin IGP, localpref 100, valid, external
Community: 11:666

• Fact 2: blackhole next hop IP is injected into BGP using static route and route-map

11-1-1#sh ip bgp 100.100.100.100
BGP routing table entry for 100.100.100.100/32, version 124
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Advertised to update-groups:
1 2 
Local
0.0.0.0 from 0.0.0.0 (10.11.1.1)
Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best




router bgp 65001
no synchronization
bgp router-id 10.11.1.1
bgp log-neighbor-changes
bgp confederation identifier 11
bgp confederation peers 65002 
redistribute static route-map V4-RM-S2B
neighbor V4-EBGP-CUST peer-group
neighbor V4-EBGP-CUST update-source FastEthernet1/8
neighbor V4-EBGP-CUST send-community
neighbor V4-EBGP-CUST default-originate
neighbor V4-EBGP-CUST remove-private-as
neighbor V4-EBGP-CUST soft-reconfiguration inbound
neighbor V4-EBGP-CUST route-map V4-RM-CUST-IN in
neighbor V4-EBGP-CUST route-map V4-RM-CUST-OUT out
neighbor 11.123.1.2 remote-as 123
neighbor 11.123.1.2 peer-group V4-EBGP-CUST
neighbor 11.123.1.2 description AS123-1-1

ip route 100.100.100.100 255.255.255.255 Null0 tag 666




ip community-list standard V4-CL-BLACKHOLE permit 11:666




route-map V4-RM-S2B permit 5
match tag 666
route-map V4-RM-S2B permit 10
match tag 65001
match source-protocol static
set origin igp
set community 11:65001




route-map V4-RM-CUST-IN permit 666
match community V4-CL-BLACKHOLE
set ip next-hop 100.100.100.100
route-map V4-RM-CUST-IN permit 2000

[Harold Ritter · Accepted solution]

By default the next hop needs to be directly connected for prefixes learnt from an eBGP neighbor. As this is not the case in an RTBH scenario, you need to disable the verification that the eBGP next is directly connected with the following configuration:

neighbor 11.123.1.2 disable-connected-check

Regards,

[yrkkmg7979]

Thank you for your reply. 

I will test your solution.

By the way, I found another solution.

When I add the red line below, it worked well

However, I really do not understand why it worked. (I was mistakenly found this solution)

I interpret

Route-map V4-RM-S2B permit 5

as below. 

Can you help me?

route-map V4-RM-S2B permit 5  ### this inject static route into BGP ###
match tag 666 ### only static route with tag 666 allowed to be injected into BGP, which is 100.100.100.100 255.255.255.255 null 0  ###

set ip next-hop 100.100.100.100 ### 100.100.100.100/24 next-hop 100.100.100.100 (this part made my lab worked, but I don't understand. ###
route-map V4-RM-S2B permit 10
match tag 65001
match source-protocol static
set origin igp
set community 11:65001

[Harold Ritter]

Yes, this will work as well, as the verification of the directly connected next hop happens before the

route-map 

is applied.

Regards,

[yrkkmg7979]

Thank you for your kind reply.

1 last question. Which method does ISPs use for RTBH? Does IPSs use "disable-connected-check"  or use my method for their clients?

Is their a better way to implement RTBH?

By the way, I appreciate for your time and answers.

[Harold Ritter]

I have seen both being used. My preference would be to set the next hop in the

route-map 

like you did.

Regards,

[Tymofii Dmytrenko]

Hello @Harold Ritter

This is an old post, but could you please shed some light on what you've said? I still do not understand why eBGP doesn't install route into RIB, if next hop (static blackhole) is not redistributed into BGP process with ITSELF as a next hop? It's like chicken and the egg...

I've just tried to re-create above such as CPE sends 10.10.1.100/32 using community 65000:666, and my PE accepts this community and sets next hop to 192.0.2.1. It doesn't work if static to 192.0.2.1 is not part of BGP process, moreover, it doesn't work if I don't sent next hop to 192.0.2.1 during redistribution... Doesn't make any sense to me as I effectively redistribute Null0 static but set next hop to 192.0.2.1 such as below

SP PE:

router bgp 65000
 redistribute static route-map S2B
 neighbor 1.1.1.2 remote-as 65001
 neighbor 1.1.1.2 route-map FROM-CPE in
!
ip route 192.0.2.1 255.255.255.255 Null0 tag 666
!
route-map FROM-CPE permit 10
 match community RTBH
 set ip next-hop 192.0.2.1
route-map FROM-CPE permit 20
!
route-map S2B permit 10
 match tag 666
 set community no-export

If I leave config as above, it sees 192.0.2.1 as inaccessible next hop, even though it is IN the BGP topology:

BGP routing table entry for 10.10.1.100/32, version 0
Paths: (1 available, no best path)
Flag: 0x4100
  Not advertised to any peer
  Refresh Epoch 1
  65001, (received & used)
    192.0.2.100 (inaccessible) from 1.1.1.2 (10.10.2.1)
      Origin incomplete, metric 0, localpref 100, valid, external
      Community: 65000:666
      rx pathid: 0, tx pathid: 0

The moment I modify my redistribution route-map to include next hop modification it works OK!

route-map V4-BGP-STATIC permit 10
 match tag 666
 set community no-export
 set ip next-hop 192.0.2.100
route-map V4-BGP-STATIC permit 20

So, the question is... why? :)

I redistribute route to 192.0.2.1 into BGP and I set next hop to 192.0.2.1 ?!!

Can't get the idea, really

As was previously mentioned 'disable-connected-check' makes it work as well.

Also, I found it works if I modify FROM-CPE route map to look like this:

route-map FROM-CPE permit 10
 match community RTBH
 set ip next-hop 192.0.2.1
 set origin igp
route-map FROM-CPE permit 20

Appreciate if you can explain this trick with next hop a bit. Regards

[Harold Ritter]

Hi Tymofii,

You do not want to redistribute the static route in BGP. This static route is only for local recursion and should not be redistributed through the network.

As mentioned before, the issue when receiving a route via eBGP is that it checks whether the next hop is directly connected or not. There are are least ways to address this. The first one is to use the "disable-connected-check" knob. The other one is to change the next on the receiving router, instead of changing it on the sending router.

Regards,

[Tymofii Dmytrenko]

Thanks @Harold Ritter