Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Oct 2009 22:41:24 +0200
From:      Vlad Galu <dudu@dudu.ro>
To:        Mike Tancsa <mike@sentex.net>
Cc:        freebsd-net@freebsd.org
Subject:   Re: quagga ignoring RTM_DELETE messages?
Message-ID:  <ad79ad6b0910271341s224ee5a1oc5890abb1a50387c@mail.gmail.com>
In-Reply-To: <200910271850.n9RIoiVD004770@lava.sentex.ca>
References:  <ad79ad6b0910261334u2f28500eia372b83fa207396a@mail.gmail.com>  <ad79ad6b0910271144i472dad73k2a3dd838f56158e@mail.gmail.com>  <200910271850.n9RIoiVD004770@lava.sentex.ca>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 27, 2009 at 8:50 PM, Mike Tancsa <mike@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@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.
>
> =A0 =A0 =A0 =A0---Mike
>
>
>> _______________________________________________
>> freebsd-net@freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
>
> --------------------------------------------------------------------
> Mike Tancsa, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0tel +1 519 651 3400
> Sentex Communications, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0mike@sentex.net
> Providing Internet since 1994 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0www.=
sentex.net
> Cambridge, Ontario Canada =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 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!



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ad79ad6b0910271341s224ee5a1oc5890abb1a50387c>