RE: High connections...

[Chris Marshall <marshall@denison.edu>]

Jeff, et al,

	Thanks for the suggestions.  Previously, we had tried similar,
but not quite as comprehensive things with the packetshaper.  However,
what we've found is that applying limits to bandwidth doesn't
effectively solve the issue for us.  Previously, we had simply limited
the amount of bandwidth the p2p apps were allowed to take through a
partition and individual policies on each p2p classification.  But due
to a sudden increase of connections demanded by each user (which we
presume was a result of the new searching methods employed by the Kazaa
v2.x clients since it was timed roughly with the release of Kazaa 2.x),
we had to shut down all known forms of p2p because we were bumping up
against the number of connections our firewall could handle (we've since
nearly doubled that limit, taking it from 25,000 max to 40,000 max, but
haven't had a trial with students on campus to make sure they won't
simply generate more connections.  Pre Kazaa v2.x we would see roughly
5-15k connections per second).  What generally happens in our situation
is a student running, say Kazaa, gets frustrated with the decreased
bandwidth available and selects "search for more sources" for each of
the dozen or so existing transfers.  Having already opened up a
substantial number of both TCP and non-TCP of connections for the
existing search and subsequent transfers, these additional searches
generate even more connections.  So, no matter how slow we make it, they
still try and generate the connections.  The only way we've found to
slow the number of opened connections is to break their ability to
create them by cutting them off from the central servers so they can't
even perform the searches.  We've lowered the TCP Idle timeout on the
packetshaper to throw away unused TCP connections more often, but don't
want to set it too low, for fear of throwing away legitimate state
sensitive connections like telnet which some of our off campus users use
(this will become less of an issue when we bring our VPN offerings
online, which is slated to be sooner rather than later).  I'm curious
now, are we unique in our situation?  Are others not feeling a pinch on
connections?  If that's the case, then perhaps we have a bigger issue to
re-evaluate.

-Chris Marshall

-----Original Message-----
From: Jeff [mailto:jkling@nac.net] 
Sent: Tuesday, January 07, 2003 2:42 PM
To: Chris Marshall
Subject: Re: High connections...


Hi Chris,

You might wish to setup a Limit partition on Inbound/Default and
Outbound/Default.  Something like 0-1M (or pick a figure that's 10% of
your connection).

Also use "sys set discthreshport 25000" to prevent DiscoveredPorts from
popping up (run in telnet).

So, now all your "discovered ports" will just end up in your Default
classes and be limited out of the way.  This will also be a preventative
against "the next napster".

By the way, you can limit bandwidth by IP, using dynamic partitions.
This is often more useful than trying to limit connections per user.
Depending on your model, you may not have enough dynamic partitions to
go around though.

Good luck!

Jeff

----- Original Message -----
From: "Chris Marshall" <marshall@denison.edu>
To: "'Packeteer Listserv'" <packeteer-edu@lists.Stanford.EDU>
Sent: Tuesday, January 07, 2003 1:26 PM
Subject: High connections...


> All,
>
> I hope everyone had a good holiday.  When we installed the latest 
> version of the Packetwise software, we didn't see as much of an 
> improvement as we wanted, and we blamed it on our tree layout.  We 
> flushed the tree and rediscovered everything, applying policies as we 
> went.  Unfortunately, since our student body doesn't return for 
> another week, we won't know if we were successful in our attempts or 
> not.  In the mean time, we've been wondering if there are ways we can 
> preemptively control applications that may pop up in the future that 
> abuse the number of connections generated similar to the way we used 
> the packet shaper to control bandwidth.  Perhaps this might be even be

> something we could bounce to the Packeteer reps as a feature request. 
> We decided to take a stab at controlling the high number of non-tcp 
> connections being generated (presumably by Kazaa v2 and Bulbster and 
> the
> like) by setting up a linux machine running IPTABLES on the link
between
> our student subnets and our firewall, the theory being that we could
> limit the number of connections each host is allowed to consume.
> However, it was only after we set it up that we realized that IPTABLES
> will only control TCP connections, which for us are behaving quite
> nicely.  I was wondering if anyone else has tried anything similar as
a
> band-aid fix, or has any thoughts on things we all could try.  At this
> point, I'm thinking of emailing our PS rep and making a feature for
> per-host connection limiting, but would like to try and articulate my
> request a little better before I bother them with a vague request.
>
> Thoughts?
>
> -Chris Marshall
> Network Engineer
> Denison University
>
> -++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**
> This message was posted through the Stanford mailing list server. To 
> subscribe/unsubscribe, send email to majordomo@lists.stanford.edu with

> "subscribe packeteer-edu" or "unsubscribe packeteer-edu" as the body.
Archive
> is at http://www.stanford.edu/group/networking/netlists/
>


-++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**==--++**
This message was posted through the Stanford mailing list server. To
subscribe/unsubscribe, send email to majordomo@lists.stanford.edu
with "subscribe packeteer-edu" or "unsubscribe packeteer-edu" as the body.  Archive
is at http://www.stanford.edu/group/networking/netlists/