After doing some initial research and wasting time on test_beds i finally came to a test setup which is quite easy to do: i set up FreeBSD on my old x41tablet (on bare metal), and do testing between the old and new laptop.

So, at the moment a have some iperf stats: on clear system iperf shows 931mb/s, on the system with netflow2 865mb/s, on fisrt test system is 20% busy in interrupts and another 15% uses iperf. In the second, inerrupts cause about 72-80% and the system is 100% CPU-busy.

So i've got the first numbers, say 850mbit per second is about 106 Megabytes per second and thats about 70Kpps - so this is what PentiumM 1.5 Gz can do without classification.

Later i can swap setups and see what tests will show on my 2,4Gz i3-370m. Now it's not that interesting. I am much more interested is classifying expences.
Next setup will be 30-50 level bpf matching, what performance impact will be on that system.

I was looking for a packet generator, decided to use pktgen from linux kernel.
Using generator is anyway important to learn how to survive on flood, and not to overload the system on DoS or something.

ng_bpf as classifier

What to do with unclassified traffic ?

It's something should be done with ng_netflow to prevent "unclassified loops", but as for now i just use special index=1 to mark traffic as unclassified when it comes from a "classificator" that way traffic goes to out1 iface.


ng_bpf test

First of all the idea of using ng_bpf will be pretty simple - doing match to first program, if it's not matched, then second, so on so force.
There is no need to use multiple ng_bpfs, one with looping links will be ok.

One thing for future consideration - to be really effective: recalculate time to time patterns and place according to frequency they are matched.
The other thing, which i already mentioned before is possibility of changing programs on fly.

Looks like a pretty simple task to generate and setup ng_bpf node according to file list with tcpdump signatures and some stats on signatures hit frequency.

Then, will need to check how an "old" bpf node can be switched to "new" one (need to check under heavy traffic processing).

Ok, up and running! Test version:


the biggest time waste was getting statistics about bpf, so the proper syntax is

ngctl msg bpf: getstats \"indata\"

where 'indata' is hook name.

So far so good.

Next:

• - high load testing, for that i'll have to get a copy of real-world traffic and feed an interface with it I think that after 3-4 hours under 100mbps it could be concluded that new scheme is functional.
• - code clean-up, remove debugging
• - check generated netflow - to see if correct classes are recorded there.

First classifier run

I did a test bed with bunch of ng_tees, ifaces, dumps and so on.

Packets seem to be broken in tcpdump - on testbed, but that doesn't affect traffic flow, which means ip-eth mismatch (most likely proper set_dlt for ngX required)

It's working!

Next step will be adding ng_bpf to classification engine and creation of some tests (say, classify icmp/ssh to different classes)

I've added some logging to the module. So, classified ping looks like this:

Step further

Realised that it's not that difficult to translate tcpdump patterns to the bpf programs, very good.

The major thing to do will be finding patterns that will cover most of the traffic, to leave as small classified data as possible (my goal is to leave no more, then 5% of traffic unclassified and, eventually, when it starts to be more then 10% start to classify it.)
The question is still open, as another way will be classifying only p2p traffic and leaving other, the weak side of it - it's unknown how actually p2p traffic was unclassified

One more thing to keep in mind - is maintenance of traffic patterns - they should be adjustable "on line". Need to check how ng_bpf handles this.

And still no real ideas on catching p2p by behaviour - either there is lots of reprogramming of ng_netflow required (this is more likely), or making of new
node - which is possible, but will kill bunch of time to get real and efficient solution.

Actually, the biggest problem of using ng_netflow is need to dig deeper in flows processing and create a kind of messaging protocol to tell classifier to mark
required traffic

One more thought and test - try to alter ToS inside packet during processing - need to think about it.
Ng_carp policing is pretty cheap in terms of resources, and it might be more expensive to forward traffic then to drop it.
If it's not - then classifier might just change ToS of packets and send them
directly out, which save some CPU and simplify processing.

Looks like netflow2 is finished

Ripped some code, responsible for sending flows in opposite direction
Added functionality to process indexes as classes, which means that all data ifaces whoose index set to non-zero are used as learning nodes.



Added functionality to send classifed data out of outCLASS iface, if there is no such iface - data is sent via out1 (default iface)

Removed iface index from flow itself (to complete searches)
added class to flow statistics


to do: sent flow class as one of netflow fields (probably TOS or smth - need to look deepere of what a hell is inside of netflow5)

to do: testbed: netflow+ng_bpf

to do: prevent classified data to be send on newflows (actually, when there is a data iface and it's index set to 0, looping is very fucking possible

to do: learn how to use ng_bpf

The hardware:

After struggling with my old-good IBM x41 tablet, waiting a few hours for kernel compile, I decided not to waste my life on slow pc waiting, and instead go buy
something that would be a little bit faster.
It was pretty poor choice here, actually, as i wanted to get something really reliable, I decided that will be the Lenovo X series again.
They are pretty expensive and choice is poor, so i got an i3 370, as it is only 15% slower then the only alternative i5-520, but 25% cheaper. Changing disk drive to OCZ Vertex 2 and adding 4G memory did really good job.
There is nothing to talk about memory - it's just PLENTY of it (6G), but what really makes incredible things - is SSD drive.
Complete boot time to Ubuntu is 14 seconds, 7 of which as BIOS splash and devices testing. That's it, in 7 seconds device with OS is up and running.
The other thing - it's virtualization possibilities. I didn't found it immediately, VTD and some other virtualization features was off in BIOS by default.
Before switching them off virtual machine usually was using 100% of a core, after switching on - ten percent.
One more thing - win7 start-up - about 10 seconds, inside virtual machine
No lags, no waitings, or something.
Just great!

I've started the projects of processing and classifying p2p traffic on fly.

The goal is achieve at least 1gps fullduplex traffic processing and classify 95 % of traffic producing no significant delays (<10ms).

Idea

Process traffic based on flows and do recognition of class based on first N packets in a flow, and keep same class for the flow without any further processing.

Another way is to process traffic only using it IP behaviour, addresses, and if possible - ports.

In reality result will be a combination

What this is for ?

General, this is a way to reduce p2p traffic, but it might be used for other applications.