wvnetflow.sourceforge.netWebview Netflow Reporter

Table of contents Overview Download New in 2013 Key features Custom traffic categorization Graphs and Table reports Clickable graphs Ad hoc query tool Netflow exporter and interface discovery and normalization Flexible data aggregation Netflow-embedded timestamps Industrial-strength flow collection and exporter manangement Open source Uses of this application that may not be immediately apparent Quality-of-Service (QoS) Security forensics Profiling WAN acceleration (WAAS, WAFS, etc) Capacity planning Tracking IT migrations Route monitoring Limitations and comparison with other packages System Requirements History and author Overview is an enterprise-focused Netflow reporter/analyzer tool featuring clickable graphs, polication that may not be immediately apparent Quality-of-Service (QoS). Netflow does not measure jitter or voice quality, but it’s excellent for proving that your network’s DSCP markings are consistent and that traffic volumes match expectations. For example, here is a graph showing both properly and improperly tagged G.729 traffic: Ignore the downward spikes (these were voice probes from NetIQ) and focus on the small ~25 Kbps purple and red rectangles between 19:20 to 20:20. These show that a G.729 flow was being marked in one direction but not the other. A click on the purple untagged area reveals the faulty endpoints. A further raw flow report will show the DSCP’s: In this case, one direction of the VoIP conversation is properly marked as DSCP EF, but the other direction isn’t. Netflow reports can also shine a light on jitter/quality measurement from sources like Cisco’s IP Service Level Agreement (IP SLA, formerly SAA or RTR). For example, in this QoS validation analysis , the first two graphs show round-trip time (RTT) and jitter for voice and data traffic on a given WAN link as reported by IP SLA. The third graph shows the Netflow traffic utilization. The big Netflow spikes correlate to increased jitter and RTT’s on the data traffic, but the VoIP traffic remains immune. The final table shows that the traffic causing the spike is properly being marked as DSCP CS1, which is used for scavenger "less-than-best-effort" service. This analysis took about an hour to do and it proves that VoIP is not impacted by non-VoIP traffic and that network spikes are properly being marked as scavenger. Are you sure that’s true in your network? Note: the /www/ipsla directory of Webview includes an IP SLA monitoring daemon and reporter. If you don’t have any other product for IP SLA (e.g., Cacti, NetIQ), then this one works pretty well. Security forensics. The ad hoc query tool is a great forensic analysis tool. In particular, the raw flow reports are chronologically accurate and can have millisecond accuracy. It’s like a sniffer trace, but it’s always running and there are no headaches of setting up monitor ports, setting up a collector, and moving around multi-megabyte capture files. Granted, Netflow doesn’t show you payload, but it does let you scan through millions of packets in seconds and quickly figure out approximately what happened and when. A Webview user at an ISP penned the article Mining Netflow on this topic in Information Security, Jan 2006. He uses it daily to root out zombies and malware on his customer’s machines. Talk about great ISP service! Another Webview user had a SQL worm outbreak that evaded their antivirus systems (the worm was brand new but the attack vector was known and unpatched). They only detected the worm when their network started crashing. At that point, sniffers could only tell you who was currently infected. Luckily, Netflow forensics with Webview was able to show that the infection began over 24 hours earlier when a SQL administrator plugged in his laptop infected with W32.Toxbot.B, which then received orders from a rogue machine in the UK to unleash the worm upon the network. Netflow forensic analysis with Webview can also reveal a lot about Internet usage behavior. ISP’s have used it to answer questions from the domestic (a father wondering just what the #@$! his son was downloading) to the felonious (child enticement, kidnapping, threatening "anonymous" emails, etc). Netflow is not CALEA "compliant", but it is a cost-effective way for network operators who are under the CALEA radar to responsibly address these questions if/when they come up. Profiling WAN acceleration (WAAS, WAFS, etc). Many enterprises are deploying WAN accelerators to speed their traffic along. Most WAN accelerators tunnel all optimized traffic, which makes it nearly invisible to Netflow on the WAN router. However, the pre-optimized traffic is available from WAN router Netflow if WCCP is used to redirect traffic to the accelerator ( example ). The pre-optimized traffic may also be available as Netflow from the WAN accelerator itself. Cisco and modern Riverbed and Expand products all support transparent acceleration which preserves the IP header of each connection ( example ). In these cases, Webview is able to report on both pre- and post-optimization traffic per category. Capacity planning. soapbox It’s amazing that many enterprises still use 5 or 15 minute sample intervals and magic numbers like "60%" to manage their WAN capacity. If you love your network users, please set all your bandwidth monitoring tools to use one minute samples I was working for a large retail client whose point-of-sale app seemed to be randomly failing in the stores. The network admin insisted the WAN links were fine. His proof was a graph of 5-minute samples that showed an average utilization of under 25%. We turned on Netflow and, within a few minutes, it becamd clear that the actual traffic volume was 10%, but that a Microsoft replication job pegged the link to 100% for a couple minutes every quarter hour. D’oh! In the well-run enterprise, capacity planning goes far beyond a macro-level view of traffic in/out an interface. Real capacity planning is about understanding how individual applications behave when faced with debilitating congestion, and that requires a micro-level view that takes QoS policies into account. It’s also about understanding difficult-to-control sources of congestion, such as unsolicited Internet traffic, flash crowding on full-mesh MPLS WAN’s, and VoIP return-to-service after power outages. And, most importantly, it’s about understanding human tolerance and monitoring to that level (e.g., how long until the user clicks the refresh button, restarts their Citrix session, or reboots their PC?). /soapbox That said, Webview does a pretty OK job at capacity planning. It can track long periods of both bandwidth: and active users: There is also an optional module called Netusage that extracts business-day data for each element and has a simplified, "manager-friendly" web interface, complete with simple line/pie graphs and easy to read reports. It also stores its data in MySQL, making the data more accessible by tools like Excel and Access. Tracking IT migrations. One non-obvious use of Webview is to generate reports on IT migration projects. For example, tracking users as they convert from one version of Exchange to another, or from one set of network switches to another. Webview can help empower you to strut into a migration status meeting with an armful of graphs and reports based on real-world data that show percentage complete, stragglers, etc. The project managers will be amazed and wonder how the network guy was able to get such wonderful data. Route monitoring. When Netflow is exported directly from a router, it includes subnet information gleaned from the routing tables. Webview includes an optional utility called routeMon which maintains a MySQL table containing the exporter, interface, destination route, and byte count from the previous day. This information could be tremendously powerful and it’s just waiting for the right problem to solve. But, unfortunately, the predominant network management paradigm is to ignore the routing table...