Linux TCクラス/フィルターの番号付け

現在、ISPレベルの企業向けのトラフィックシェーピングソリューションに取り組んでおり、興味深い（一種の哲学的な）問題に遭遇しました。

システムが処理するエンドポイントの数（約20k程度）を見ると、より多くのユーザーのトラフィックをポリシー化/シェーピングする必要がある場合に何が起こるか少し心配になりました。現在、ネットワーク全体でHFSCシェーピングツリーを使用しているので（tc-hfscを参照してください。ほとんどがよく知られているHTBと同じです）、より多くのClassIDを使用する必要があります（明らかに、通信網）。私が見つけた問題は、TC ClassIDの種類が限られていることでした-それらは16ビットの数値であり、このソリューションによって形成された最大64kユーザーの可能性があります。

同様に、TCフィルターを効率的に管理したい場合（「すべての手法を使用しない」など）、個々のフィルターエントリを削除または変更できる必要があります。（LARTC [1]のハッシュテーブルに似たものを使用しています）。繰り返しますが、これで動作していると思われる唯一の方法は、個々の優先順位を使用してすべてのフィルターに番号を付けることです（tc filter add dev ... prio 1）。この目的に使用できる他のパラメーターはありません。残念ながら、prioも16ビットのみです。

私の質問は次のとおりです：「tc class」コマンドの32ビットclsid、「tc filter」の32ビット優先度（またはその他の変更ハンドル）など、利用可能な「識別子スペース」を拡大するための良い方法はありますかコマンド？

どうもありがとう、

-mk

（ところで、これは「64kユーザーですべての人に十分なはずです」シナリオに行かないことを願っています...）

64kのユーザーにアップストリームクラスとダウンストリームクラスを配置し、それぞれのインターフェイスを同じインターフェイスに配置しないでください。使用しているインターフェイスごとにハンドラーを繰り返すことができるため、インターフェイスを追加します。これを行うには、信じられないほどの作品/サーバー/ NICが必要です。サーバーがクラッシュすると、64kユーザーがオフラインになります（そのトラフィック量で簡単にクラッシュします）。ネットワークカードを通過する各パケットは、フィルターによってチェックおよび分類され、キューに入れられるクラスに送信されることを忘れないでください。これは、64kの顧客を持つISPゲートウェイのNICにとって多くの作業です。主に、現在あるすべてのビデオストリーム（適切にキューイングするのが難しい）です。

1台のマシンですべてのトラフィックを処理する代わりに、トラフィック処理を2台のマシンに分割できます（3台目のマシンを使用）。トラフィックは、単に送信元IPアドレスに基づいてルーティングできます。そのため、IP範囲を均等に分割できれば、1万人のユーザーが最適になります。

もちろん、必要に応じて3台以上のマシンを使用できます。これは、Linuxカーネルにパッチを適用して他のハッキングを行うよりも良いと思う。つまり、トラフィックシェーピングは複数のマシンに分散されます。中央ノードは、トラフィックを適切な処理ノードに転送するだけです。