Re: [RE: Any good method to check network overload?]

[Joerg Over <over () dexia de>]

->> >From: swin <swin () student dlut edu cn>
->> >    You all misunderstood me! what I want isn't a tool to check network
->> >flow or just want to have it report.

Hunh.

->> >    I'm doing a research  to find a good model to judge if network
->> >is overload automaticlly,it may be a good algorithm but not a tool.no
->> >matter to use ntop or mrtg, it just give a  statistic of network flow,
->> >this is not hard to achive.but my problem is how to  judge network
->> >overload in real-time and offer a countermeasure ,but not a monitor tool.

You will have to monitor the one way or other, and you will have to monitor
over time. Of course, the time frame is up to you. A realtime indicator of
a momentary overload on an ethernet segment is the red collision led on
your hub or nic. But that happens in the quietest of networks, only takes
two packets and the birthday paradoxon.

->> >is not reliable.as we known ,we can get the data in realtime just like 
->> >intop can do,but with this data how can we say at certain time the
network
->> >is overloaded ,what we need is a benchmark to decide if it is overloaded,
->> >but what should this benchmark be and how to get this benchmark are the
->> >problems.

On an ethernet you could try and count the collisions/time frame. After
all, overload on an ethernet manifests in accumulating collisions up to an
amount where throughput severely suffers. That'd be probably easier then
watching the requests/throughput ratio or any other measurement of
roundtrip time resp. bandwidth.

On linux, you can see the number of collisions using ifconfig. You can
reset the accumulated numbers with ifconfig as well. You might also be able
to use the /proc system.

You might have to correlate those events from several segments and machines
of the network.
As for "countermeasure", I guess I don't know how you want to achieve that
except implementing more bandwidth, switches etc, but certainly not in
realtime.

Sorry if that was proposed before and escaped my attention.

hth, jo

(btw., I also fail to see the connection with security issues.)