collisions are not particularly useful in a "fully-switched" (sub-) network.
For that you really would need to sample the LAN port octet counters on the
switch/router and compare them against maximum expected (or SLA) bandwidth.
And even that would usually be far above what your servers could tolerate.
"Countermeasures" would almost invariably have to involve
connections/source/second and bandwidth/source limiting, enforced either by
the router/switch or the servers themselves. That gets complicated and
subtle, particularly when tuning reactive/threshold schemes.
I assume that the only "security" issue involved is DoS, of the servers,
services, routers, IDS and/or firewalls.
C.
>From: Joerg Over [mailto:over_at_dexia.de]
>Sent: Monday, March 10, 2003 1:15 PM
>To: security-basics_at_securityfocus.com
>Subject: Re: [RE: Any good method to check network overload?]
>
>
>->> >From: swin <swin_at_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.)
_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.
http://join.msn.com/?page=features/featuredemail
Received on Mar 12 2003
Intro
