quagga ignoring RTM_DELETE messages?

[Vlad Galu]

On Tue, Oct 27, 2009 at 8:50 PM, Mike Tancsa <mike at sentex.net> wrote:
> At 02:44 PM 10/27/2009, Vlad Galu wrote:
>>
>> On Mon, Oct 26, 2009 at 10:34 PM, Vlad Galu <dudu at dudu.ro> wrote:
>> > Hi list, sorry for the noise here.
>> >
>> > I'm experiencing a weird issue with the latest Quagga from ports, on a
>> > 8.0-RC1. It was configured to redistribute kernel routes to BGP, which
>> > it does. However, when a route is deleted, it's still announced to the
>> > BGP peer. RTM_DELETE was picked up by "route monitor"... This exact
>> > same setup used to work before upgrading to RELENG_8. Am I missing
>> > something?
>> >
>> > Thanks,
>> > Vlad
>> >
>>
>> So, everybody happy with Quagga + RELENG_8?
>
> I havent tried it yet. Can you post your quagga config and I will try and
> recreate here on my RELENG_8 test box.
>
>        ---Mike
>
>
>> _______________________________________________
>> freebsd-net at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
> --------------------------------------------------------------------
> Mike Tancsa,                                      tel +1 519 651 3400
> Sentex Communications,                            mike at sentex.net
> Providing Internet since 1994                    www.sentex.net
> Cambridge, Ontario Canada                         www.sentex.net/mike
>
>

Sure Mike, thanks!

Here's the bgpd.conf:

-- cut here --
router bgp <my AS number>
 bgp router-id <my router id>
 redistribute kernel
 neighbor <my neighbor> remote-as <my AS number>
 neighbor <my neighbor> next-hop-self
 neighbor <my neighbor> soft-reconfiguration inbound
 neighbor <my neighbor> route-map filtru out
route-map filtru permit 10
 set community 5483:10000 6746:10000 additive
 set ip next-hop 192.168.192.168
-- and here --

A sniffer runs on this machine, watching all inbound traffic for DDoS
attacks, and nullroutes the attacked IP. What it actually does is to
add a static route towards the attacked IP, through 127.0.0.1, with
the following flags set:
RTF_UP|RTF_GATEWAY|RTF_HOST|RTF_BLACKHOLE|RTF_STATIC. Then, the static
route is seen by Quagga and redistributed into BGP. After a while, the
monitoring software removes the static route, and Quagga used (on 7.x)
to also stop announcing it to the neighbor. For some reason, this
second part doesn't happen anymore, although the static route is
clearly not in the routing table anymore, and "route monitor" sees the
kernel's RTM_DEL message (and so should Quagga).

For the record, the same setup almost works with OpenBGPD, the only
difference being that I have to replace 127.0.0.1 with another
reachable (directly connected) IP when setting the static route,
otherwise OpenBGPD ignores it (which I suspect is due to some internal
check). OpenBGPD correctly stops exporting the static route to the BGP
peer once it's removed from the routing table by the monitoring
software.

Thanks for looking into this!