Be a Good BitTorrent Citizen -or- Cisco Router vs. P2P File Sharing
by Trainman
I am a network engineer by day and a voyeuristic hacker by night (mostly enjoying the pursuits of others with an occasional "experiment" of my own). In my day job, I am the network engineer for a public library with more than 25 branches and have to keep numerous network connections up and productively working. We provide free and completely open public computers and Wi-Fi.
I love reading and learning about all of the hacker activities, but of course I have a job to do at the library. So my goal is to always make sure that there are easier pickings elsewhere and that no hacking takes place on my network and on my watch. Our library, like most, has the philosophy of sharing and openness, and therefore our goal is to allow everyone to do their own thing. The same goes for our public computers and Wi-Fi. For the most part we have no restrictions on who can use them and we don't filter or limit the use (exceptfor time on the public PCs so that everyone gets their turn). For years now, this has been working fine. As more and more people now depend on the Internet, the need for bandwidth has increased significantly at most of our branches over the last couple of years. So we keep working hard to get funds to buy more bandwidth. Peer-to-peer file sharing does give us a little grief since, as most of you know, it has the knack of taking all the bandwidth it can get (both upstream and downstream) and running for long periods of time. If we get a lot of complaints from other users, we may try to block a given MAC address or limit bandwidth per user at a select location, but for the most part it's a family of sharing that works pretty well.
Until recently...
As it turned out, a group of peer-to-peer file sharers (not sure how many, but numerous MAC/IP addresses) decided to set up shop on the Wi-Fi network at one of our branch libraries and didn't just suck the life out of the network (which we are used to just tolerating at times), but also appeared to take down our router, requiring a reboot to recover. Even though we like to be open to everyone, since this was not only slowing the network but requiring manual reboots to recover, it was time for me to take action for the good of the masses. After some frustrating afternoons, luckily I have figured out what was happening and how to control it for now. Let me describe the problem and the solution.
Each of our libraries uses a Cisco router (v) for all routing, firewall, DHCP, and NAT services. By default, the NAT is configured to allow unlimited NAT translations for each user and maintain them for 24 hours. This works great for all of the typical users but, as it turns out, these settings don't work well for a large number of "peer-to-peer" BitTorrent users borrowing and sharing a large number of files. The problem started when performance of the network would grind to a halt every afternoon after school and typically require a reboot of the router. At first we thought it was a bandwidth issue or router performance issue, but after some monitoring I determined that it was the huge number of translations in the Cisco NAT table created by a handful of users. Being a public library, we are a fully open network. But my job at that point became one of insuring that everyone shares nicely, and clearly a few users were now preventing everyone else from using the Wi-Fi, public, and staff computers. So now it was time for me to be the bad guy and try to lock down the network.
We initially thought about trying to prevent the P2P file sharing but knew that is often a futile game of "Whac-A-Mole" since the ports and protocols used vary widely (a "feature" of P2P file sharing). We had already set up a P2P bandwidth limiter with Cisco QoS (using Cisco's policy-map, class-map, and service-policy commands) as a matter of good network management and it was not controlling this particular problem.
I then turned my attention to the NAT table since that seemed to be the real problem - when it grew unreasonably large, CPU performance of the router grew to the point where overall network performance suffered. At first, I just tried shortening the aging time down from 24 hours to a few hours (and even minutes in some tests) but this was still futile as many many NAT mappings formed quickly as files were shared out. I then started working on managing the number of mappings and found the perfect Cisco IOS commands to solve our problem.
The ip nat translation max-entries command allows you to specify the maximum number of mappings per user. After a little experimentation, we found that limiting the NAT mappings to a maximum of 300 per user worked great. Most users need somewhere around 10 to 20 for casual surfing, watching YouTube, and checking email - and the P2P users can still exchange files, albeit with far fewer people at one time.
In summary, our Cisco routers now have the following configuration commands as part of our standard setup:
and router CPU performance has dropped back down to reasonable levels.
The Cisco engineers seem to have thought of everything - the trick is learning about a command and then figuring out how to best apply it in a particular situation. Hopefully, this short article will help other network engineers solve this problem more quickly and easily than we did. And now we seem to have achieved a win-win-win - all of our users still have Internet access, they all have a "fair" amount of bandwidth, and I can start relaxing again.
Since I don't know who the P2P users are, I can't find out how they perceive the network performance now, but I do know that the majority of our users are now much happier.
class-map match-any P2P-class match protocol bittorrent match protocol edonkey match protocol fasttrack match protocol gnutella match protocol kazaa2 match protocol winmx match protocol directconnect match protocol irc match protocol cuseeme match protocol skype match protocol ssh match protocol novadigm policy-map P2P class P2P-class police cir 8000 conform-action transmit exceed-action drop interface FastEthernet0/1 description INTERNET - COX Cable ip address 72.214.242.26 255.255.255.0 ip access-group 150 in no ip redirects no ip upreachable no ip proxy-arp ip nbar protocol-discovery ip nat outside ip virtual-reassembly duplex auto speed auto ntp disable fair-queue no cdp enable service-policy input P2P ip nat translation timeout 1200 ip nat translation tcp-timeout 1200 ip nat translation udp-timeout 1200 ip nat translation max-entries all-host 300