[quagga-users 9438] Re: FreeBSD, BGP and blackholes

Steve Bertrand iaccounts at ibctech.ca
Wed Mar 12 00:50:28 GMT 2008


> Ok, this particular issue has officially caused me to come back to work 
> to attempt to rectify the situation, and at the same time, is driving me 
> nuts. I'm sure many here who have used Cisco gear before will know 
> exactly what I am trying to do, so what I am hoping for is that this is 
> something someone can share a config for on a Quagga router.

Just to keep the archives up-to-date, I have done hours worth of testing
and I thought I'd write back to the list with findings. Although I won't
post my pages of notes containing all the tests I've done and their
conclusions, I will state my findings thus far:

- FreeBSD 6.2
- Quagga 0.99.9_5

In order to successfully null-route (blackhole) a collection of IP
prefixes that are received as a community within BGP via a route-map on
localhost, one must sacrifice at least one /32 IP address that is
currently assigned to a physical network interface within the machine.

All my manner of testing falls back on the fact that a next-hop address
that is directed to an IP assigned to a virtual, or locally logical 
interface (ifconfig create, or loopback respectively) will fail in the 
context of route-map.

The problem has been with 100% degree of certainty isolated to either
FreeBSD 6.2, zebra's implementation of the way it communicates between
bgpd and/or the kernel table while dealing with route-map/next-hop, or a
combination of the two. If zebra is disabled, bgpd accepts the
advertisement and applies the next-hop as per the configuration. Of
course, without zebra running, the kernel route table is not updated.

It is not a problem with the core functionality of zebra (I don't
think), as statically null-routing an IP or IP block to ANY null
interface's IP works fine.

All in all, there are a few posts floating around the Google that come
very close to my exact problem, without from what I can see a proper
solution.

Although this is my devel lab, the IP's I've shown are mostly in real
production. I try my best to use production IP addresses in development
to best simulate when it has to be rolled out. Here is how I got it to
work, while sacrificing a public IP that is within an assigned subnet to
a physical interface on the box:

kernel# kldload if_disc
kernel# ifconfig disc0 create 192.0.0.1/24
kernel# route add 208.70.104.104/32 192.0.0.1

router(route-map-config)# set ip next-hop 192.0.0.1

I would really like to know if the situation I have been facing has been
found on other versions of FBSD or other OS's in general.

If this is a simple case of upgrading my OS, then we will do it so long
as it can be confirmed. If not, I would really like to help rectify the
problem. My understanding is that Quagga is not to be classified as an
IOS emulator, but the closer it comes to it, the better :)

If anyone is interested in this issue and it is an actual problem, I
will happily help with as much time as I can, provide peering for
testing with my problematic Quagga gear and Cisco equipment to simulate
the problem and can configure the box for SSH access for investigation. 
I can quite handily find my way around C code, particularly testing 
patches, although I'm far more proficient with Perl simply by trade and 
attrition.

Thanks for all the feedback/suggestions.

BTW, how did you get along with your dual Gigabit with Bell, Mike ;)

Steve








More information about the Quagga-users mailing list