[99048] in North American Network Operators' Group
Re: Network Operations Guide
daemon@ATHENA.MIT.EDU (Sam Stickland)
Fri Aug 31 07:22:53 2007
Date: Fri, 31 Aug 2007 12:21:25 +0100
From: Sam Stickland <sam_mailinglists@spacething.org>
To: Bill Nash <billn@billn.net>
CC: Greg VILLAIN <gregoire.villain@dailymotion.com>,
Joel Jaeggli <joelja@bogus.com>, deepak@ai.net, nanog@nanog.org
In-Reply-To: <Pine.LNX.4.64.0708240934130.23309@pegasus.billn.net>
Errors-To: owner-nanog@merit.edu
Bill Nash wrote:
> On Fri, 24 Aug 2007, Greg VILLAIN wrote:
>
>
>> Thing is, Zebra/Quagga doesn't seem to have any sort of "external connector"
>> to withdraw the routes in a decent format for analysis purposes (xml, csv,
>> plain list...).
>> Last time we tried, Zebra/Quagga broke down when we installed SNMP support (to
>> locally query the routing table on the soft router).
>>
>> Anyone know about any solution for such BGP data collection ? (OpenBGPd ?)
>> Thanks in advance for any hint.
>>
>
> I built a perl daemon using Net::BGP and DBI that inserted and removed
> routes, on update, into an SQL db. I could then query to my hearts
> content, beating up a db with full routes with all the efficiency of SQL.
> It's simple as hell and works great.
>
It's just a shame that there aren't any BGP extensions in common use
that allow it to advertise all the routes in the BGP table, not just the
best ones (1). It would also only allow you to monitor BGP routes. Even
forming adjancies with the other routing protocols won't catch
everything. Perhaps you need to find stray static routes that got added,
but aren't being redistributed into any routing protocol.
Ultimately I feel that this problem would require the vendors to provide
decent route reporting mechanisms rather than attempting to gather this
information one hop removed.
Sam
1) see the archives for a discussion of problem. As well as needing to
advertise all the routes, the problem is that the BGP withdrawal message
does not carry enough information to specify which path is being withdrawn.