Re: Route table prefix monitoring

[Warren Kumari <warren () kumari net>]

On Sep 10, 2009, at 7:23 AM, Joel Jaeggli wrote:

> Olsen, Jason wrote:
> > Howdy all,
>
> > What I'm left thinking is that it would have been great if we'd had a
> > snapshot of our core routing table as it stood hours or even days  
> > prior
> > to this event occurring, so that I could compare it with our current
> > "broken" state, so the team could have seen that subnet in the core
> > table and what the next hop was for the prefix.  Are there any tools
> > that people are using to track when/what prefixes are added/withdrawn
> > from their routing tables, or to pull the routing table as a whole at
> > regular intervals for storage/comparison purposes?  It looks like
> > there's a plugin for NAGIOS, but I'm looking for suggestions on any
> > other tools (commercial, open source, home grown) that we might  
> > take a
> > look at.  For reference, we are running Cisco as well as Juniper kit.
>
> Periodic table dumps, or even a log of the updates from a quagga  
> router
> inside your infrastructure could provide this information. That in a
> nutshell is what routeviews and other collectors do for the dfz  
> routing
> table.

There is also an Internet draft for the BGP Monitoring Protocol (hhttp://tools.ietf.org/html/draft-ietf-grow-bmp-02) 
.
This draft provides for a method whereby the BGP speakers export their  
received updates to a central collector. This allows you to get route  
views in (more) real time, with no more screen scraping (and probably  
much lower CPU as well). Personally I think its an awesome idea and is  
something that we have need for a long long time (over the years I  
must have written 7-8 screen scrapers to get BGP RIB info, and they  
always suck).



Draft Abstract:
This document proposes a simple protocol, BMP, which can be used to  
monitor BGP sessions.
BMP is intended to provide a more convenient interface for obtaining  
route views for research purpose than the screen-scraping approach in  
common use today.
The design goals are to keep BMP simple, useful, easily implemented,  
and minimally service-affecting. BMP is not suitable for use as a  
routing protocol.


W

> > Feel free to drop me your thoughts off-list.
> >
> >
> >
> > Thank you for any insight ahead of time,
> >
> >
> >
> > -Jason "Feren" Olsen

For every complex problem, there is a solution that is simple, neat,  
and wrong.
                -- H. L. Mencken