Re: Questions on Iperf still actual

[Jon Zeeff <jzeeff --at-- internet2.edu>]

Conceptually, you could use multicast to protect yourself from receiving
traffic that you don't want to receive.  Ie, have the client send to
a multicast
group and have the server only listen for a legitimate time period. 
The server could also stop listening if the bandwidth was
excessive.

Except for multicast, the Internet isn't designed for DOS
protection.


At 03:22 PM 8/27/2003 -0400, Bob Riddle wrote:
> When speaking of bandwidth, I guess
> I was thinking of UDP packets  (./iperf -s -u), but I get the
> picture - windoze machines will shower the server with UDP packets
> whether it's listening or not ...
>
> I guess I'm not so concerned about the "through-put" as much as
> I am the duration.  So for TCP connections the "-time"
> param might be the only concern.  I'd like to be able to have a
> server parm that says "no more than XXX" from any client"
> where XXX could be some number of bits or it could be some duration of
> time.
>
> Make sense?
>
> Kevin Gibbs wrote:
> > On Wed, 27 Aug 2003, Bob Riddle wrote:
> >
> >  
> > > I have a  question related to running an iperf
> > > server.    Suppose I want 
> > > to have a iperf server continously available for quick infrastructure 
> > > testing.  Suppose I don't trust folks not to abuse this continously 
> > > running server ... suppose I don't want to honor any client request with 
> > > "-t" greater than ... a couple of seconds and any bandwidth
> > > test where 
> > > "-b" is greater than ... 12mbps  ... is there any way I
> > > can ensure that 
> > > no matter what parms the iperf client chooses my iperf server won't go 
> > > beyond X seconds and Y bandwidth?
> > >    
> >
> > Well this is not really an easy request. First if you are using TCP there 
> > is no way to limit speed on client or server side effectively. It would
> > be 
> > easy to react to the configuration parameters that are sent using the 
> > newer code (post 1.7), but if you really do not trust folks to not edit 
> > their source to abuse that as well then you could get in trouble. If the 
> > clients are windows machines then you have no recourse because windows 
> > does not properly listen to ICMP messages saying a UDP connection is 
> > closed or not available. If any of these approaches sounds beneficial let 
> > me know.
> >
> > Kevin
> >
> >
> >  
>
>
> -- 
> Bob Riddle
> (bdr --at-- internet2.edu)   
> Technologist,Internet2
> 3025 Boardwalk, Suite 100        
> Ann Arbor, Michigan  48108
> Business Phone: 734.913.4257      Fax
> Number:  734.913.4255
>
> "Opportunity is missed by most people because it is dressed in
> overalls and looks like work" Thomas Edison