I'd argue that if you are running with 69000 connections, you could be running into multiple problems. I cant comment on StarOS specifically, but one of the reasons we upgarded our servers from 2.4Kernal to 2.6 kernel was because of connection tracking table size. 2.6 kernels allowed management of the number of connection (able to delete from table) without rebooting and terminating all connections. By the way, performance degragation was limited due to Clocking (# of ticks per second), that was not updated until kernel 2.6. One of the issues is that poorly written applications or virus/spyware dont close sessions properly, so they stay there in the table as inactive state but still in the table for the specified duration (it might be 7 days by default?). (its purposely designed to do that). Linux doesn't work fast with tons of connections in its tables, and when you get tons of connections it will show heavy speed degregation for users. My point is that you might not only be running into a NAT issue and available ports, but also a problem of low performance when to many connections in the table. In our deployments we turned connection tracking off on all our Staros APs, because they didn't have enough memory or processing power to deal with it, and then upgraded our Kernels on our core Linux routers that we used connection tracking on.
There are other reason why having 1700 subs to a single NATted IP might be a bad idea, so I'd recommend changing that regardless of the cause of the problem you are currently troubleshooting. For example, what do you do if a user's IP gets blacklisted due to AUP report? You then have 1700 customers blacklisted. If the core router fails, you have 1700 people down. Etc, etc. If one user gets a virus, all uses get hammered when all teh connections are terminated. We had one car dealership that added 120,000 entries to the connection table within about 8 hours. It was due to a poorly written WAN application. They fixed it, and it curred the problem. But it was tough to deal with the problem, and identify why it was occuring. But my point is... why risk all the subs, if all it takes is a single customer to create a connection problem issue? What you'll likely want to do is write some scripts to analyze the content of the connection table. To determine if the majority of connections are getting eaten up by just a few customers, or equally distributed between customers? And determine the percentage that are active sessions versus inactive sessions?. Tom DeReggi RapidDSL & Wireless, Inc 301-515-7774 IntAirNet - Fixed Wireless Broadband -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: [email protected] Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
