eBGP Limitation?

[Rolando Valenzuela]

Playing with BGP and trying to configure a Remotely-Triggered Black Hole (RTBH) I noticed that eBGP wont accept routes that has a different "next-hop" value.

My configuration:

############# BLACK-HOLE-ROUTER #############
!
ip route 169.254.1.1 255.255.255.255 Null0
!
route-map BLACKHOLE permit 10
set origin igp
set community no-export
set ip next-hop 169.254.1.1
!
interface Loopback11
ip address 11.11.11.11 255.255.255.255
!
interface Loopback22
ip address 22.22.22.22 255.255.255.255
!
interface Loopback33
ip address 33.33.33.33 255.255.255.255
!         
interface Loopback44
ip address 44.44.44.44 255.255.255.255
!
router bgp 64555
 bgp router-id 192.168.0.2
 bgp log-neighbor-changes
 no syncronization
 network 11.11.11.11 mask 255.255.255.255
 network 22.22.22.22 mask 255.255.255.255
 network 33.33.33.33 mask 255.255.255.255
 network 44.44.44.44 mask 255.255.255.255
 neighbor 192.168.0.1 remote-as 65000
 neighbor 192.168.0.1 active
 neighbor 192.168.0.1 route-map BLACKHOLE out
!

############# R1 #############
!
ip route 169.254.1.1 255.255.255.255 Null0
!
router bgp 65000
 bgp router-id 192.168.0.1
 bgp log-neighbor-changes
 no syncronization
 neighbor 192.168.0.2 remote-as 64555
 neighbor 192.168.0.2 activate
 neighbor 192.168.0.2 soft-reconfiguration inbound
!

As soon as the highlighted command is added, R1 stops accepting all the networks.

Now if I force it to be an iBGP session with:

############# BLACK-HOLE-ROUTER #############

router bgp 64555
 neighbor 192.168.0.1 remote-as 64555

############# R1 #############

router bgp 65000
 neighbor 192.168.0.2 remote-as 64555
 neighbor 192.168.0.2 local-as 64555

It works fine :(

I would like to know why it does that, where on the standard says that and if there's a workaround always using eBGP.

[Harold Ritter]

Hi Rolando,

This is normal as eBGP does a directly connected check by default. Just add the following command to solve this issue.

 neighbor x.x.x.x disable-connected-check

 Regards,

[Rolando Valenzuela]

Thank you Harold!

I tried that, and it didn't worked :( I applied that on R2 (the router receiving the routes).

Please note that the BGP sessions works, I'm changing the next hope because I'm pointing it to Null0 (part of the RTBH), all the examples are using iBGP but I'm still wondering why it doesnt work using eBGP.

Thanks for the suggestion.

Rolando A. Valenzuela.

[Harold Ritter]

Hi Rolando,

Try removing the BLACKHOLE route-map on the sending router and putting it as an inbound route-map on the receiving router. This should fix the issue.

Regards,

[Rolando Valenzuela]

It does, but then the advertisement that R1 does to the rest of the iBGP cloud don't have the next-hop updated and I'm force to update all the nodes and is what I was trying to avoid.

Not sure what BGP feature is avoiding R1 to learn the routes but I guess my only option is to force the iBGP :(, dont you think?

Thanks for the help.

Rolando A. Valenzuela.

[Harold Ritter · Accepted solution]

Hi Rolando,

The route-map for RTBH is normally implemented on the receiving routers, but I think I can provide you yet another workaround to get it to work with the BLACKHOLE route-map applied on the sending router.

Replace the "neighbor x.x.x.x disabled-connected-check" with the following command on the receiving router:

neighbor x.x.x.x ebgp-multihop 2

Let me know if it works for you.

Regards,

[Rolando Valenzuela]

I tried those commands separately and never together hahaha that make the trick :)

Thanks for the help Harold!

[Harold Ritter]

I'm glad it worked for you Rolando. Have a great weekend!