[WISPA] Bandwidth Cap Implementation
Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
Re: [WISPA] Bandwidth Cap Implementation
Matt; Thanks for sharing your information. Frank On 5/6/2010 11:11 PM, Matt Larsen - Lists wrote: Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org
Re: [WISPA] Bandwidth Cap Implementation
Hey Matt, Can you give us your customers' reaction to this change after a few weeks? ryan On Thu, May 6, 2010 at 11:11 PM, Matt Larsen - Lists li...@manageisp.comwrote: Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ WISPA Wants You! Join today! http://signup.wispa.org/
Re: [WISPA] Bandwidth Cap Implementation
EXCELLENT post. This is worth framing. Thank you very much for the information and publishing this with us. Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 “Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill On Fri, May 7, 2010 at 2:11 AM, Matt Larsen - Lists li...@manageisp.com wrote: Since there has been a lot of discussion about bandwidth caps on this list recently, I thought that I would share the one that we recently implemented, along with some details on how we are enforcing it and how we established the caps. Going back to day 1, we have had a 3gig cap on broadband customers with a $25/gig surcharge for anyone exceeding that amount. When we were using all StarOS V2, the radius accounting information was keeping fairly close track of the bandwidth per customer. Fast forward six years, and that cap was so low as to be a joke -- and we had not been enforcing it. It was also very difficult to collect accurate accounting data - StarOS evolved and the radius accounting became useless in version 3, so some access points were tracking it and others were not. We also have a few Tranzeo and Mikrotik access points in the system and no good way to collect the individual subscriber download information from them either. After looking at several different options for collecting the bandwidth traffic information, we decided to use open source tools to develop our own solution. We installed a switch between our core and edge routers -- behind the NAT so that it could see all customer's IP addresses -- and mirrored a port to our new collection server. The collection server is a Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily reports are mailed out to our techs list to show the customer who are nearing or over their caps. A customer page was created that shows the customers how much bandwidth they have used, how much they have left before charges and what their overage charges are (if any). The customer page also shows their historical usage trend for the last 12 months -- starting with April 2010 when we started collecting the information. Starting on June 1, we will bill overages as a separate charge to the customers on the 1^st of the month, regardless of their billing anniversary. The process of implementing this was quite interesting. Out of 2000+ customers, 80 used more than 10 gigs for the month. One customer - a 1 meg subscriber at the far eastern edge of our network, behind seven wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on the far western side of our network, downloaded 110gig. We called them and found out that they were watching a ton of online video. We discovered a county government connection that was around 100gig -- mostly because someone in the sheriff's department was pounding for BitTorrent files from 1am to 7am in the morning, and sometimes crashing their firewall machine because of the traffic. We also discovered that there was 80-100meg of stateless udp type traffic traversing our routed network and getting to our core router. Revised firewall rules on the APs fixed this problem. The majority of the rest of the subs on the list were either online video watchers, people with virus problems or who had left filesharing programs running on their computers. After reviewing the usage records, we decided on the following cap sizes for our plans: Package Monthly Download Cap 384k 10 gigabytes 640k 10 gigabytes 1 meg 20 gigabytes 2 meg 40 gigabytes 3 meg 50 gigabytes 4 meg 60 gigabytes 8 meg 80 gigabytes Additional capacity over cap $1 per gigabyte over the cap I feel that these caps are more than generous, and should have a minimal effect on the majority of our customers. With our backbone consumption per customer increasing, implementing caps of some kind became a necessity. I am not looking at the caps as a new profit center -- they are a deterrent as much as anything. It will provide an incentive for customers to upgrade to a faster plan with a higher cap, or take their download habits to a competitor and chew up someone else's bandwidth. This has been an educational experience, and probably one that we should have gone through a couple of years ago. I would like to thank the people on the WISPA and Butch Evans' Mikrotik lists for their input while we were developing this system. Matt Larsen Vistabeam.com WISPA Wants You! Join today! http://signup.wispa.org/ WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives:
