From owner-freebsd-net@FreeBSD.ORG Tue Oct 27 20:41:45 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73EFD1065745 for ; Tue, 27 Oct 2009 20:41:45 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 102FE8FC26 for ; Tue, 27 Oct 2009 20:41:44 +0000 (UTC) Received: by mail-bw0-f213.google.com with SMTP id 5so163287bwz.3 for ; Tue, 27 Oct 2009 13:41:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.14.83 with SMTP id f19mr1238754faa.92.1256676104445; Tue, 27 Oct 2009 13:41:44 -0700 (PDT) In-Reply-To: <200910271850.n9RIoiVD004770@lava.sentex.ca> References: <200910271850.n9RIoiVD004770@lava.sentex.ca> From: Vlad Galu Date: Tue, 27 Oct 2009 22:41:24 +0200 Message-ID: To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: quagga ignoring RTM_DELETE messages? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 20:41:45 -0000 On Tue, Oct 27, 2009 at 8:50 PM, Mike Tancsa wrote: > At 02:44 PM 10/27/2009, Vlad Galu wrote: >> >> On Mon, Oct 26, 2009 at 10:34 PM, Vlad Galu 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 bgp router-id redistribute kernel neighbor remote-as neighbor next-hop-self neighbor soft-reconfiguration inbound 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!