[LARTC] Suggestions/Pointers on where to begin my search for a

[LARTC] Suggestions/Pointers on where to begin my search for a

[Bill Blum]

[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]

Hi-
I'm working in the IT department of a small liberal arts university-- we're
getting *massacred* by P2P traffic.

Informal testing/probing indicates that about 60% of our traffic from the
dorms was P2P-- we've taken the initial step of hardlimiting the dorms to no
more than 40% of outgoing university bandwidth.  Also, we've blocked the
'standard' ports for KaZaa, Gnutella, etc. in our firewall/switch setup
(Cisco Catalyst 6500 between us and the net at large)....

However, the Powers That Be want a better, more effective solution---
without a performance hit for the VOIP phones on campus.

Any suggestions on what part of the FM I should be reading/etc, so that I
can make a better informed decision about how to proceed?

Regards,
Bill Blum

-- 
Bill Blum
Bill.Blum@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 926 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Suggestions/Pointers on where to begin my search for

[Mohan Sundaram]

Bill Blum wrote:
> Hi-
> I'm working in the IT department of a small liberal arts university-- 
> we're getting *massacred* by P2P traffic.
> 
> Informal testing/probing indicates that about 60% of our traffic from 
> the dorms was P2P-- we've taken the initial step of hardlimiting the 
> dorms to no more than 40% of outgoing university bandwidth.  Also, we've 
> blocked the 'standard' ports for KaZaa, Gnutella, etc. in our 
> firewall/switch setup (Cisco Catalyst 6500 between us and the net at 
> large)....
> 
> However, the Powers That Be want a better, more effective solution---   
> without a performance hit for the VOIP phones on campus.  
> 
> Any suggestions on what part of the FM I should be reading/etc, so that 
> I can make a better informed decision about how to proceed?
> 
> Regards,
> Bill Blum
> 
> -- 
> Bill Blum
> Bill.Blum@gmail.com <mailto:Bill.Blum@gmail.com>
> 
Try a Linuc m/c in between with ipp2p patch on iptables. Have you tried 
using the NBAR facility on the CISCO. That should also help.

Mohan Sundaram
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Suggestions/Pointers on where to begin my search for

[Andy Furniss]

Bill Blum wrote:
> Hi-
> I'm working in the IT department of a small liberal arts university-- we're
> getting *massacred* by P2P traffic.
> 
> Informal testing/probing indicates that about 60% of our traffic from the
> dorms was P2P-- we've taken the initial step of hardlimiting the dorms 
> to no
> more than 40% of outgoing university bandwidth.  Also, we've blocked the
> 'standard' ports for KaZaa, Gnutella, etc. in our firewall/switch setup
> (Cisco Catalyst 6500 between us and the net at large)....

Would be more liberal to try and allocate bandwidth per user - Do they 
have real IPs?

> 
> However, the Powers That Be want a better, more effective solution---
> without a performance hit for the VOIP phones on campus.
> 
> Any suggestions on what part of the FM I should be reading/etc, so that I
> can make a better informed decision about how to proceed?

Well I like to think Linux Qos could do it, but can't point you any 
manual as such. Classifying traffic can be hard and will need ongoing 
maintenance, but it's doable. I have no experience with the size of 
network you have - I guess the cisco can't do anything more for you.

What to do and what you can do also depends on how much bandwidth you 
have and how many users - you wan't prio for voip, do you know how many 
voip calls your link can sustain without any other traffic.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Suggestions/Pointers on where to begin my search for a

[David Sims]

Hi,

On Mon, 18 Sep 2006, Andy Furniss wrote:

> Bill Blum wrote:
> > Hi-
> > I'm working in the IT department of a small liberal arts university-- we're
> > getting *massacred* by P2P traffic.
> >
> > Informal testing/probing indicates that about 60% of our traffic from the
> > dorms was P2P-- we've taken the initial step of hardlimiting the dorms
> > to no
> > more than 40% of outgoing university bandwidth.  Also, we've blocked the
> > 'standard' ports for KaZaa, Gnutella, etc. in our firewall/switch setup
> > (Cisco Catalyst 6500 between us and the net at large)....
>
> Would be more liberal to try and allocate bandwidth per user - Do they
> have real IPs?
>
> >
> > However, the Powers That Be want a better, more effective solution---
> > without a performance hit for the VOIP phones on campus.
> >
> > Any suggestions on what part of the FM I should be reading/etc, so that I
> > can make a better informed decision about how to proceed?
>
> Well I like to think Linux Qos could do it, but can't point you any
> manual as such. Classifying traffic can be hard and will need ongoing
> maintenance, but it's doable. I have no experience with the size of
> network you have - I guess the cisco can't do anything more for you.
>
> What to do and what you can do also depends on how much bandwidth you
> have and how many users - you wan't prio for voip, do you know how many
> voip calls your link can sustain without any other traffic.
>
> Andy.
>

You don't mention your ISP situation, but an approach I have had good luck
with is the classification of traffic by source and then the distribution
of that traffic over more than a single ISP connection using LARTC in
order to achieve classes of service... This is a simple approach that
doesn't preclude doing traffic shaping on one or any of your ISP links.
It also provides redundant ISP connectivity for disaster
recovery/managment.

So, you might have one ISP connection for high priority traffic (like
VoIP) along with some VIP users and a second one (perhaps nearer capacity)
for the dorms... This gets you in a situation where you can tweak the
traffic to/from the dorms without potentially disrupting more business
oriented traffic....

I have been doing it this way for a local municipality with good result
for a couple of years now. City business goes out over a 3 meg link and
the library traffic (where there is lots of public access and P2P
activity) goes out over it's own T-1 but it all runs over a common
infrastructure and is routed by a Linux router using LARTC source routing
with some traffic shaping on the T-1....

Also, Tobi Oetiker's MRTG is your friend. I run MRTG on all outbound
traffic and make the resulting graphs fairly public so peer pressure can
have some effect without requiring never ending cat and mouse with the
main abusers.... There is also a package called 'darkstat' that will
aggregate traffic statistics by 'top 25' hosts and display it for you.
This provides a good mechanism for the old 'heart-to-heart' conversation
with your abusers.... ;) In any event, a good place to start your search
for solutions might be Policy Routing Using Linux, Matthew G. Marsh, ISBN
0-672-32052-5

Dave
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Suggestions/Pointers on where to begin my search for

[Mohan Sundaram]

Andy Furniss wrote:
> Bill Blum wrote:
>> Hi-
>> I'm working in the IT department of a small liberal arts university-- 
>> we're
>> getting *massacred* by P2P traffic.
>>
>> Informal testing/probing indicates that about 60% of our traffic from the
>> dorms was P2P-- we've taken the initial step of hardlimiting the dorms 
>> to no
>> more than 40% of outgoing university bandwidth.  Also, we've blocked the
>> 'standard' ports for KaZaa, Gnutella, etc. in our firewall/switch setup
>> (Cisco Catalyst 6500 between us and the net at large)....
> 
One way of doing this is to use a Linux machine in between and use ipp2p
netfilter plugin to identify P2P traffic. Even if we shut out standard
ports, these apps work on commonly used ports like 80,110,25 etc. :-(

You can rate limit using ipp2p or mark packets using ipp2p and then
shape that traffic using tc.

Mohan

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc