大規模システム（約2000ユーザー）でのトラフィック制御に最適なソリューションは何ですか？
次の状況：私たちは、地元の居住ホールのインターネット接続を管理している学生のグループであり、合計で約2000人のエンドユーザーがいます。
トラフィックポイントシステムがあり、MBごとにコストポイントがダウンまたはアップロードされ、新しいポイントが時間ごとに追加されます。現時点では、ユーザーがすべてのポイントを使い果たしたときに、ユーザーのインターネットアクセスをブロックします（DebianゲートウェイルーターのiptablesのREJECTポリシーにユーザーを配置します）。
ユーザーの帯域幅のみを制限したいと思います。これを行うための最良の方法は何ですか？
簡単な答えは、ユーザーのスイッチポート（主にCisco Catalyst 3550）にレート制限を設定することです。ただし、これは望ましくありません。独自のネットワーク内および大学のネットワークへのトラフィックは無制限のままである必要があるためです。 Cisco IOSで特定の宛先または送信元IP範囲（つまり、出力と入力の両方）を持つパケットに対してのみ帯域幅を制限する方法はありますか？何も見つかりませんでした。
もう1つの方法は、ゲートウェイルーターのトラフィックを制御することです。いくつかの解決策が思い浮かびます。
tcまたはtcng-どちらもかなり難解な構文を持っているようで、どちらもIPごとのトラフィック制御を行うための優れた機能を提供していません。非常に多くの人専用のQDiscは、おそらくルーターの速度を大幅に低下させます。さらに、両方のドキュメントはかなり古くなっています。
shorewall-構成の構文はかなりきちんとしているようですが、この量のトラフィックとユーザーを処理できるかどうか、およびIPごとのトラフィック制限に適しているかどうかはわかりません。
pfSense-私たちのような目的を意図したOSのように見えます。ただし、ゲートウェイルーターを完全に再インストールする必要があります。他のBSDシステムはなく、pfSenseには非常に優れたトラフィックアカウンティング機能が必要です（現在、そこでfprobe-ulogとulog-acctdを使用しています）。
あなたの経験は何ですか？どのソリューションが私たちのニーズに適合し、最も簡単に保守できるでしょうか？他にアイデアはありますか？
当社のシステムに関する追加情報が必要な場合は、遠慮なくお問い合わせください。
前もって感謝します。
[〜＃〜] edit [〜＃〜]：iptablesとtcを使用してシステムを実装しました。
すべてのユーザーは/ 28サブネット、VPN IP（両方とも10.0.0.0/8から）および外部IPを持っており、すべてが1つのiptablesチェーンを介して操作されます。このチェーンには、単純なRETURNという1つのルールしかありません。
5分ごとに、Pythonスクリプトは、これらのルールのバイトカウンターを読み取ります。これにより、カウンターがリセットされ、PostgreSQLデータベース内のユーザーのトラフィックポイントアカウントが更新されます。
ユーザーのポイントバランスが特定のしきい値を下回ると、このユーザー用に2つのtcクラスが作成され（1つはゲートウェイルーターの着信インターフェイス用、もう1つはゲートウェイルーターの発信インターフェイス用）、IPはこれらのクラスに属するtcフィルターに入力されます。クラスはHTBによって速度が制限されています。
fprobe-ulogおよびulog-acctdを使用する以前のシステムと比較すると、バイトカウントはiptablesによって行われるため、これははるかに高速です。
ユーザーのネットワーク速度が大幅に向上しました。
セットアップ全体を再構成する（つまり、Debianを置き換える）ことにどれほど興味があるか、またはゲートウェイの後ろにこのようなものを配置することがどれほど実現可能かはわかりませんが、FreeBSDには dummynet）として知られるipfwの機能があります 。専用のハードウェアトラフィックシェーパーを入手したくないように思われるので、これはあなたにとっての選択肢かもしれません。現在、プロキシゲートウェイの1つを介してインバウンドとアウトバウンドのSMTPトラフィックをチョークし、老朽化したNFSバックエンドシステムが圧倒されて応答しなくなるのを防ぎます。
ルールセットのスクリプトとインテリジェントな構成を使用すると、何千もの個別のIPアドレスをトラフィック制御できるようになります。
Trafficpanel 解決策のようです。他の機能の中で：
- 接続ごとの最大HTTP速度の制限
- ローカルネットワークホストごとのWebリソースのトラフィックの合計量を制限する
- ローカルネットワークホストごとにインターネットトラフィックをログに記録する
- ローカルネットワークホストごとの最大トラフィック速度の制限
- ローカルネットワークホストごとのインターネットトラフィックの合計量を制限する
実際、これを試したことはありませんが、問題ないようです。
tcは正常に機能するはずです。現在のiptablesルールを変更して、トラフィックを拒否するのではなくマークを付けることです。その後、少数のtcルールを使用して、マークされたフローにトラフィックシェーピングを適用できます。
また、スロットルされたユーザーのリストを管理するためのipsetを見てください http://ipset.netfilter.org/
ダミーネットは私の意見では非常に良い提案です。しかし、iptablesは トラフィックシェーピング にも対応していると確信しているので、Debianボックスでそれを行うことができます。
何を使用しているのかを尋ねる必要がありますが、ResTekの担当者は、インターネットの境界にサービス品質機能を実行するアプライアンスを持っています。未分類のストリームにはデフォルトの優先順位があり、ルールに基づいて他のトラフィックに優先順位が付けられます。ボーダーアプライアンスで最優先事項としてリストされているSquidベースのキャッシングクラスターも運用しているため、これは実際に販売されている優先機能です。ネットワーク上の人々は、標準の（そしてやや厄介な）優先順位でWebサーフィンをするか、プロキシを使用して非常にきびきびとした応答を得るかを選択できます。当然のことながら、遅延の影響を受けやすいが帯域幅が狭いため、ゲームサーバーの優先リクエストも受け取ります。
ゲームサーバーのリクエストを処理する作業はかなりの量ありますが、プライベートサーバーから離れるゲームが増えるにつれ、それらはゆっくりと進んでいます。全体的に、それは彼らにとってかなりうまくいくと聞いています。 BitTorrentのようなものが他のすべてのトラフィックを圧倒するのを防ぎ、それでも人々のYouTubeの読み込み時間を速く保つことができます。
その多くのユーザーがいると、単純なソフトウェアベースのもののほとんどが壊れ始めます。
Packeteerおよび同様のデバイスを検討することを検討してください。最近では、帯域幅を購入するよりもほとんど高価になっています（米国とヨーロッパでは、オーストラリアの貧しい人々は依然として非常に高いレートです）。