Route table prefix monitoring

Fri Sep 11 14:57:25 UTC 2009

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