Re: Network Operations Guide

[Sam Stickland]

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.