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. - billn
On Fri, 24 Aug 2007, Bill Nash wrote:
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.
Just to answer a bunch of off-list mails en masse, no, I do not have a copy of this code for distribution. I wrote it originally for an ex-employer, so I don't have a copy. I plan on rebuilding it, it's fairly simple, so if you have use cases for a tool like this, shoot me an email off list with your thoughts. Time permitting, I'll rebuild and post. I need it for some of my own purposes anyway, might as well make it suck less. - billn
On 25/08/2007, at 7:04 AM, Bill Nash wrote:
On Fri, 24 Aug 2007, Bill Nash wrote:
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.
Just to answer a bunch of off-list mails en masse, no, I do not have a copy of this code for distribution. I wrote it originally for an ex-employer, so I don't have a copy. I plan on rebuilding it, it's fairly simple, so if you have use cases for a tool like this, shoot me an email off list with your thoughts. Time permitting, I'll rebuild and post. I need it for some of my own purposes anyway, might as well make it suck less.
An alternative that I've been meaning to tinker with for some time might be to use OpenBGPd/zebra/quagga dumping to a file, and load that file in to SQL. I like that a bit more than INSERT/DELETE direct to SQL, because those dump files are dumps of all BGP messages, as well as table states, so you can move to any point in time when diagnosing problems. A quick google reveals http://nms.lcs.mit.edu/software/bgp/bgptools/ - tools that can deal with SQL and MRT dump files. -- Nathan Ward
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.
participants (3)
-
Bill Nash -
Nathan Ward -
Sam Stickland