cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1281
Views
7
Helpful
8
Replies

Throttle

Robert Craig
Level 3
Level 3

Hello. I need some help in throttling a user. I know this person is using some type of Bittorrent client because a capture showed he was downloading in the high 40,000+ UDP range. I have tried creating an ACL that matches his ip and applying it in a policymap on the router, and even a rate limit command matching the ACL outbound to the land with his IP. I can't seem to slow his traffic down. Does anyone have any pointers? Thanks!

1 Accepted Solution

Accepted Solutions

Your torrents class map is set to "match all" which is the default. You should delete this class map and type in:

class-map match-any TORRENTS

match protocol bittorrent

match protocol edonkey

match protocol directconnect

match protocol fasttrack

match protocol gnutella

match protocol kazaa2

I noticed that you're using protocol discovery on your interface. Are you matching on bittorrent with nbar? BTW, match all means that in your packet, you'd have to match on all of the protocols at the same time in order to make a match. It acts as a logical AND instead of a logical OR.

HTH, John *** Please rate all useful posts ***

View solution in original post

8 Replies 8

smehrnia
Level 7
Level 7

Hi robert,

you have to use exceed-actine drop with the rate limit to actualy limit him!

or you can use to police the traffic for that particular class, in the policy-map along with an exceed-actine drop to limit him!

example:

policy-map LIMIT

  class TORRENT

    police 10000000 exceed-action drop

HTH,

plz Rate if it helped,

Soroush.

Hope it Helps!

Soroush.

John Blakley
VIP Alumni
VIP Alumni

Robert,

If you truly know that it's bittorrent, you may be able to  create a policy like this:

access-list 10 permit 192.168.1.5 <--- the host you suspect

class-map Torrent

match access-group 10

match protocol bittorrent

policy-map Torrent

class Torrent

police 128000 exceed drop

int f0/0

service-policy out Torrent

When/if the user is truly match on torrent traffic and their address matches, the policy map will allow them to 128k and then drop everything past that. Of course, everything else from that host will be allowed a full speed because this will only match on torrent traffic and that host. You can also check to see if it's truly torrent traffic by enabling nbar discovery on the inside interface before applying this policy map:

int fa0/1 (lan interface)

ip nbar protocol-discovery

To check, do a "sho ip nbar protocol-disc protocol bittorrent" and you should see hit counts on the Bittorrent line.

*Edit* You may have to play with the direction of the service policy though. The traffic coming in is what you want to control as well as what's going out, so the policy could possibly be applied to both directions in order to be effective. I don't have a way of testing this unfortunately.

HTH,

John

HTH, John *** Please rate all useful posts ***

Thanks guys for the help. Unfortunately, what I've tried I think isn't working. Maybe I am applying it to the wrong interface or in the wrong direction? Below is my config, scrubbed of course. Can you see what I missed?

Your torrents class map is set to "match all" which is the default. You should delete this class map and type in:

class-map match-any TORRENTS

match protocol bittorrent

match protocol edonkey

match protocol directconnect

match protocol fasttrack

match protocol gnutella

match protocol kazaa2

I noticed that you're using protocol discovery on your interface. Are you matching on bittorrent with nbar? BTW, match all means that in your packet, you'd have to match on all of the protocols at the same time in order to make a match. It acts as a logical AND instead of a logical OR.

HTH, John *** Please rate all useful posts ***

Ahhh, I gotcha. I didn't understand the difference. However when I do a 'show ip nbar protocol discovery', the traffic under the Torrent protocols isn't being identified. I'm seeing a ton of traffic under the 'unknown' category. Now, this is my head would mean that the user is using the 'encrypted' button in his client or something.

That's quite possible. Do you know if he the user is going to multiple destinations? The last time I had seen this, I had 1 user going to 20 or 30 different destinations. If you can find a common denominator, you should probably match on that...or get with his supervisor if he's not an exec

If he's really connecting to high 40000 ranges, you could block those destinations for him with something like:

ip access-list ext BlockTorrent

permit tcp host 192.168.1.5 any range 40000 65535

class-map BlockTorrent (match-all will be default)

match access-group name BlockTorrent

Then everything else that was stated earlier. This would block this person from going to destination ports 40000-65535, but would allow them to still nat out on the high ports to any destination ports on not in the 40000-65535 range. That may help.

HTH,

John

HTH, John *** Please rate all useful posts ***

Yeah, I'm gonna give that a try. What interface and what direction should I apply this?

You could try to apply it to the LAN interface on the router to see if you could control it there. If that doesn't work, you could apply outbound on the wan side, but if you're natting that could pose some other challenges like being able to identify the flow after natting occurs. The other problem is that I'm assuming that this user is downloading. BitTorrent works by making connections to others but also allowing others to make connections to you. The problem comes in that you can control the user outbound, but not necessarily inbound.

Sent from Cisco Technical Support iPhone App

HTH, John *** Please rate all useful posts ***
Review Cisco Networking for a $25 gift card