Changes between Version 7 and Version 8 of MoreAbout
- Timestamp:
- 11/29/08 00:49:24 (2 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
MoreAbout
v7 v8 4 4 NFDB is a convenient front-end to database storage of !NetFlow datagrams. It provides a series of views that detail "Top 10" lists for data such as ''Top Services'', ''Top Source Hosts'', ''Top Destination Hosts'', and ''Top Connections''. Users are easily able to drill-down through the information to get a more accurate view of network anomalies and traffic abusers. 5 5 6 Representation of directional flows might be misleading to the experienced !NetFlow user. To overcome limitations with PF-based agents ([http://www.openbsd.org/cgi-bin/cvsweb/ports/net/pfflowd/ pfflowd], pflow(4)), NFDB actually aggregates the two flows into a single directional flow. This representation better conveys the sort of analysis it was designed for. As these agents mature and become more "standard" (e.g. correct interface indexing), we may see the application adapt to those changes.6 Representation of directional flows might be misleading to the experienced !NetFlow user. To overcome limitations with PF-based agents ([http://www.openbsd.org/cgi-bin/cvsweb/ports/net/pfflowd/ pfflowd], [http://www.openbsd.org/cgi-bin/man.cgi?query=pflow&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html pflow(4)]), NFDB actually aggregates the two flows into a single directional flow. This representation better conveys the sort of analysis it was designed for. As these agents mature and become more "standard" (e.g. correct interface indexing), we may see the application adapt to those changes. 7 7 8 8 == What It Isn't == 9 The aforementioned views are almost always sorted by total bandwidth per connection, although the focus of NFDB isn't as a bandwidth accounting utlity. SNMP-based applications are much more adept at this. The !NetFlow protocol isn't designed for accurate "real-time" monitoring. !NetFlow agents report the totals of their bandwidth usage only after the session is complete. For example, OpenBSD's [http://www.openbsd.org/cgi-bin/man.cgi?query=pflow&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html pflow(4)]exports !NetFlow v5-compatible datagrams after the state is expired. This means the summary information is received well after the connection finished, and provides no insight to the "peaks and valleys" that a typical connection experiences.9 The aforementioned views are almost always sorted by total bandwidth per connection, although the focus of NFDB isn't as a bandwidth accounting utlity. SNMP-based applications are much more adept at this. The !NetFlow protocol isn't designed for accurate "real-time" monitoring. !NetFlow agents report the totals of their bandwidth usage only after the session is complete. For example, OpenBSD's pflow(4) pseudo-device exports !NetFlow v5-compatible datagrams after the state is expired. This means the summary information is received well after the connection finished, and provides no insight to the "peaks and valleys" that a typical connection experiences. 10 10 11 11 It's not very fast. Storing large amounts of ongoing network traffic is easy. Querying that same information quickly (with continuous inserts) is '''substantially''' more difficult. I've made great strides in my understanding of the database features, but a professional DBA could almost certainly squeeze more ''juice'' out of it. That said, many users will never notice this limitation. I've tested it in a production environment with two pairs of CARP firewalls on DS-3 and Gigabit drops. It was very responsive up to 3M rows (typically one day of flows in that scenario). Anything beyond that would cause noticeable load time delays (>5s). This was on a Dell !PowerEdge 1750, YMMV.
