Implementation of data collection tools using NetFlow for statistical ...
Implementation of data collection tools using NetFlow for statistical ...
Implementation of data collection tools using NetFlow for statistical ...
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
4 <strong>Implementation</strong><br />
4 <strong>Implementation</strong><br />
This chapter will describe the different methods available, as well as which methods were chosen<br />
and more importantly, why they were chosen.<br />
4.1 Choice <strong>of</strong> method<br />
This chapter will present the chosen method to solve each problem, explaining why a certain<br />
solution was chosen over the others.<br />
4.1.1 Collecting the <strong>data</strong><br />
Protocol decision<br />
Several widely used protocols are available today, all <strong>of</strong> which gather network traffic in their own<br />
way. The most prominently used protocols are <strong>NetFlow</strong>, sFlow and IPFIX.<br />
All Cisco devices which support flow accounting only support <strong>NetFlow</strong>, which is their own<br />
solution. One benefit <strong>for</strong> <strong>using</strong> <strong>NetFlow</strong> is that it captures all <strong>of</strong> the IP traffic without missing<br />
anything – every packet it accounted <strong>for</strong>. This needs especially to be taken into consideration if one<br />
is <strong>using</strong> IP billing, i.e. charging customers <strong>for</strong> the amount <strong>of</strong> traffic they use. Furthermore, it might<br />
be advisable to utilize <strong>NetFlow</strong> if the network already consists <strong>of</strong> Cisco devices, as it is the only<br />
supported flow-protocol.<br />
Another protocol is sFlow, which is based on sampling. Due to the nature <strong>of</strong> sampling it is very<br />
probable <strong>for</strong> sFlow to miss some <strong>of</strong> the packets, since only one in every N packets are <strong>for</strong>warded to<br />
a collector <strong>for</strong> actual analysis. However, the greatest benefit sFlow have is its ability to be protocolindependent.<br />
Whereas <strong>NetFlow</strong> can only account <strong>for</strong> IP traffic, sFlow can gather any protocol such<br />
as IPX and AppleTalk. It is also capable <strong>of</strong> operating on Layer 2 and as such does not require Layer<br />
3 routing like its peers. Thus, sFlow is a strong competitor in an environment running multiple<br />
protocols.<br />
In the end, <strong>NetFlow</strong> was chosen as the protocol <strong>of</strong> choice <strong>for</strong> several reasons; the company utilizes<br />
Cisco devices throughout their network, and it allows <strong>for</strong> the capture <strong>of</strong> smaller flows since every<br />
flow is accounted <strong>for</strong>. This was decided primarily <strong>for</strong> DDoS-attacks in mind in which attackers<br />
might try to avoid detection by creating smaller flows but with an increased numbers <strong>of</strong> hosts. This<br />
rules out sFlow since it is not supported on Cisco devices. IPFIX was rejected since <strong>NetFlow</strong> would<br />
suffice <strong>for</strong> the company's needs and the ease <strong>of</strong> configuring – it works by just enabling a few<br />
commands in an already running device.<br />
Program decision<br />
Although the choice <strong>of</strong> s<strong>of</strong>tware was already decided upon by the company, several <strong>tools</strong> exist:<br />
• <strong>NetFlow</strong> Analyzer by ManageEngine [6] is such a tool. It comes in three editions, with<br />
prices varying from $795 up to $9995 as <strong>of</strong> June 2012. Understands IPv4 as well as IPv6.<br />
27
Change language