We moved the core of Loughborough's student halls networking to Cisco 3550-12G switches over the Summer of 2003. Not only do they do inter-VLAN IP (not IPX or AppleTalk!) routing, but they also have a fairly flexible bandwidth management/QoS implementation. We thought that it would be interesting to try using this to rate limit common peer to peer filesharing ports.
Blocking common P2P ports altogether is a bit more problematic, since we don't really want to disable legitimate services using these as ephemeral ports. Equally there are a lot of people trying to use non-standard ports for peer to peer and other nefarious purposes, but we have another hack to nobble them - see elsewere on this site.
These are just some quick notes on our config - partly as an aide memoire, and partly to help anyone else trying to do something similar.
To use QoS on your 3550, you need to first turn it on:
mls qos
Cisco say you also need to disable flow control, e.g.
int range gi0/1 - 12
flowcontrol send off
Doing the above will result in your switch pausing for a while as it reinitialises some subsystems. Expect a spanning tree recalculation and OSPF events if you are using your switch for routing.
It took me a while to suss how the QoS mechanism works on the 3550. Although you can match packets according to an access control list by associating it with a class-map, if you want to match on multiple criteria then you need to define a class map for each of the criteria and a parent class map which refers to the other ones. Thus we have:
class-map match-all P2VLANSv1
match vlan 220-248
class-map match-all P2PORTSv1
match access-group 101
class-map match-all P2Pv1
match class-map P2VLANSv1
match class-map P2PORTSv1
To affect packets which match both extended ACL 101 and traffic on VLANs 220 to 248.
Next, a policy-map which refers to the parent class map should be created. This is where you decide how much bandwidth to allocate to the matching traffic and what to do with anything which goes over the limit. As an experiment I tried giving our known peer to peer ports just about the minimum possible bandwidth:
policy-map P2Pv1
class P2Pv1
bandwidth 10000
police 8000 10000 exceed-action drop
For each interface which is to be rate limited, you need to apply the policy map created above using a service-policy declaration, e.g.
interface GigabitEthernet0/1
description link to wherever
switchport trunk encapsulation dot1q
switchport mode trunk
no ip address
flowcontrol send off
service-policy history
service-policy output P2Pv1
spanning-tree portfast trunk
Here's a sample of the sort of ACL you might want to put into place...
access-list 101 permit tcp any eq 412 any
access-list 101 permit tcp any eq 1214 any
access-list 101 permit tcp any eq 4661 any
access-list 101 permit tcp any eq 4662 any
access-list 101 permit tcp any eq 4663 any
access-list 101 permit tcp any eq 4664 any
access-list 101 permit tcp any eq 4665 any
[...]
access-list 101 permit tcp any eq 6346 any
access-list 101 permit tcp any eq 6347 any
access-list 101 permit tcp any eq 6881 any
access-list 101 permit tcp any eq 6882 any
access-list 101 permit tcp any eq 6883 any
access-list 101 permit tcp any eq 6884 any
access-list 101 permit tcp any eq 6885 any
access-list 101 permit tcp any eq 6886 any
access-list 101 permit icmp any any
access-list 101 deny tcp any any
Please note that if this was your only approach to bandwidth management it could still easily be defeated by people switching to non-default ports or (for the above example) UDP based protocols.
The 3550s also appear to support NetFlow - the commands exist in IOS but only partial NetFlow stats get transmitted to your collector. The IOS release notes say that these are unsupported commands ;-)
$Id: 3550-qos.html,v 1.2 2004/07/07 08:06:52 martin Exp $