It’s one thing to collect high volume NetFlow and quite another to report on it and that’s really where the rub lies. The amount of engineering necessary to collect millions of flows per second and write them to some type of backend really isn’t all that hard for a seasoned developer. Getting the data back out of the storage in a timely manner, is where expert design comes into play. And really, how fast is fast? Well, Google sort of sets that bar and they are generally pretty much instant with results. Drawing comparisons to Google however, really isn’t all that fare. First of all, the Google architecture is supported by thousands of servers. Most enterprise NetFlow collection consumers don’t have the deep pockets necessary to build out “a similar to Google” architecture. They want it all on one system or at least perceived as one system.
A single system however, is not always the best choice. Sometimes sending all the flows back from a remote location over a WAN can cause congestion. In these situations, distributed collectors makes the most sense. Enterprise NetFlow systems will provide single interface for viewing the data across dozens of collectors all while keeping the distribution transparent to the user. In other situations, sending the flows up to the cloud makes the most sense where a cluster of servers can support the collection. The vendor can help you decide on which strategy is the best fit for your environment.
If you speak with the vendor, some will tell you that their systems scales to millions of flows per second while dropping nothing. The question is: how do you know if they are or aren’t dropping flows? To reliably answer this, the system should be counting and reporting on the flow sequence numbers. If the collector is missing flow sequence numbers (MFSNs) from a specific router and only one router, the problem is likely the router or the network. If the collector is seeing MFSNs across all routers that are sending flows, then the problem starts to look like the collector not keeping up. Without monitoring for MFSNs, we can’t be sure if the collector is collecting everything we expect it to.
When problems strike, a fast responsive interface is great but, it needs to be combined with ease of filtering. The ability to quickly include this and exclude that really speeds up the investigative process. All vendors claim the best interface. Make sure you try it out for yourself and watch any short tutorials they may have to help you appreciate the vendor specific features.
[Gartner predicts that 645 million smartphones] http://www.channelinsider.com/c/a/Mobile-Devices/Mobile-Management-Styles-Driven-by-Consumerization-Gartner-634465/ will be sold in 2012 – a 40% increase from this year. Cell phone reception is often weak on the interior of office buildings and smartphone owners will have their WiFi on. Many companies are allowing employees onto the corporate net with their personal smart phones in hopes of increased productivity.
Employees using Corporate Bandwidth with Personal Phones
This big increase brings with it big concerns when it comes to network monitoring:
1. How much bandwidth are all these additional devices collectively using and is it impacting business critical applications?
2. What applications and web sites are users hitting and what impact are these distractions having on productivity and how often?
3. What are the security implications introduced by allowing these devices onto the net? Many of these hand held devices do not have antivirus software.
Given that the traffic from a cell phone browsing a web site looks nearly identical to that of a PC hitting the same site, how can a company determine the amount of Internet bandwidth utilized by the combined smart phone devices? To answer this, we need a new flow element.
All hardware accessing the LAN utilizes a six byte hexadecimal MAC address. The first three bytes of this address is reserved to identify the vendor. For example, an iPhone may have an address of E4:CE:8F:C2:9D:AA. The first three bytes E4:CE:8F identifies the vendor ‘Apple’ and it is likely that thousands of other iPhones start with the same 3 bytes. The remaining three bytes C2:9D:AA are unique to the individual iPhone.
<<< monitoringMobilePhoneTraffic.png >>>
Nearly a dozen vendors (e.g. Cisco, Enterasys, Exinda, Juniper, nBox, Sonicwall) are now exporting MAC information in their flow exports. Learn how to export [MAC address with Flexible NetFlow] http://www.plixer.com/blog/netflow/getting-mac-addresses-from-netflow-v9/ . Setting up a simple network monitor will help you proactively keep track of this traffic.
If your NetFlow or IPFIX hardware can export Username, you could click on a username and see the number of devices authenticated by the same user.
<<< sonicwall-Ipfix-username.png >>>
Monitoring BYOD traffic is a growing concern and the above report can be run against flow exports from the Cisco ASA, Palo Alto Networks and the SonicWALL (example above). Vendors are always looking for new and innovative ways to filter on this data.
KEY WORDS:
network monitoring
flexible netflow
network monitor
monitoring mobile phone traffic
monitoring byod traffic
big concerns when it comes to network monitoring:
1. How much bandwidth are all these additional devices collectively using and is it impacting business critical applications?
2. What applications and web sites are users hitting and what impact are these distractions having on productivity and how often?
3. What are the security implications introduced by allowing these devices onto the net? Many of these hand held devices do not have antivirus software.
Given that the traffic from a cell phone browsing a web site looks nearly identical to that of a PC hitting the same site, how can a company determine the amount of Internet bandwidth utilized by the combined smart phone devices? To answer this, we need a new flow element.
All hardware accessing the LAN utilizes a six byte hexadecimal MAC address. The first three bytes of this address is reserved to identify the vendor. For example, an iPhone may have an address of E4:CE:8F:C2:9D:AA. The first three bytes E4:CE:8F identifies the vendor ‘Apple’ and it is likely that thousands of other iPhones start with the same 3 bytes. The remaining three bytes C2:9D:AA are unique to the individual iPhone.
<<< monitoringMobilePhoneTraffic.png >>>
Nearly a dozen vendors (e.g. Cisco, Enterasys, Exinda, Juniper, nBox, Sonicwall) are now exporting MAC information in their flow exports. Learn how to export [MAC address with Flexible NetFlow] http://www.plixer.com/blog/netflow/getting-mac-addresses-from-netflow-v9/ . Setting up a simple network monitor will help you proactively keep track of this traffic.
If your NetFlow or IPFIX hardware can export Username, you could click on a username and see the number of devices authenticated by the same user.
<<< sonicwall-Ipfix-username.png >>>
Monitoring BYOD traffic is a growing concern and the above report can be run against flow exports from the Cisco ASA, Palo Alto Networks and the SonicWALL (example above). Vendors are always looking for new and innovative ways to filter on this data.
KEY WORDS:
network monitoring
flexible netflow
network monitor
monitoring mobile phone traffic
monitoring byod traffic