07-01-2012 06:35 AM - edited 03-04-2019 04:50 PM
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!
Solved! Go to Solution.
07-01-2012 09:54 AM
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.
07-01-2012 07:06 AM
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.
07-01-2012 07:41 AM
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
07-01-2012 08:53 AM
07-01-2012 09:54 AM
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.
07-01-2012 10:13 AM
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.
07-01-2012 11:03 AM
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
07-01-2012 11:55 AM
Yeah, I'm gonna give that a try. What interface and what direction should I apply this?
07-01-2012 06:47 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide