On Sun, Nov 14, 2010 at 11:32:10AM -0600, Richard A Steenbergen wrote:
On Sun, Nov 14, 2010 at 08:59:33AM +0000, Paolo Lucente wrote:
On Sat, Nov 13, 2010 at 09:17:55PM -0600, Richard A Steenbergen wrote:
Remember that every RIB in your network can and will have a unique best path selection (thanks to the EBGP > IBGP rule if nothing else), and if you have a network of any size at all you'll probably have to deal with multiple exits to the same network. Even if you were only concerned with analyzing external traffic, you'd still need to collect a RIB per edge router using an IBGP feed.
Agree.
In my network this would put you well over 10 million paths, and consume several gigs of ram, not to mention the load of doing the routing lookups themselves.
If the collector is able to keep up with the pace of the export protocol, it will not get killed by a couple of BGP lookups per flow/sample. About the memory figure: reducing information overlap among the RIBs results in storing a full BGP table in few tens of MBs. On 10M paths that translates in less than a GB of memory.
analysis inside your network you'd need a feed from every router, and maybe even active participation in your IGP.
This is separate thing. Relying only on telemetry information for such a task is one of the possible approaches - perhaps the quicker, if enabled ad-hoc for troubleshooting, but not necessarily the smarter.
It CAN be done, but it's not pretty, and I don't think any existing free software has been tested under these kinds of conditions.
Define pretty: is it pretty to move control-plane information over and over via NetFlow or sFlow? But most importantly: why passing the concept challenging conditions is something free software should be run far away from?
So when a vendor says "we support sFlow", make sure they actually support the message types and fields you need. :)
Indeed, agree. Cheers, Paolo