同じインターフェイスを介して実行される2つのサービスがあります。
サービスの目的は、大量のデータを転送しながら高い帯域幅を維持することです。
サービスBは低レイテンシを目指しています。
サービスBパケットはいつもサポートサービスパケット。
以下を行うにはTC構造が必要です。
- 速度制限サービスAとB
- サービスBパケットに優先順位を付けると、サービスAパケットはレイテンシに0％の影響を与えます。
- 他のサービスが送信されない場合は、各サービスが回線全体を活用するか制限に達するようにします。
class htb classid x私は速度/上限の制限があるかもしれません（例：y：0を扱う）、子として（自動的にクラスy：1、y：2、y：3を生成します）、フィルタsrc ipリダイレクトを使用できるhtb構造qdisc prio試しました。パケットをy：1 / y：2に送信します。
しかし、うまくいかないようです。そしてそのサブフローは
すべてclass xゼロとして表示されます。 （tc -s class/qdisc/filter show dev dev表示用）
フィルタを見ると「クリック」がはっきりと見えるため、データを正しくリダイレクトする必要があります。
私が実行したコマンドは次のとおりです。
tc qdisc add dev dev root handle 1: htb
tc class add dev dev parent 1:0 classid 1:1 htb rate 10gbit ceil 10gbit
# class x
tc class add dev dev parent 1:1 classid 1:2 htb rate 10gbit ceil 10gbit
# auto creates classes 21:1, 21:2 and 21:3
tc qdisc add dev dev parent 1:2 handle 21: prio
# example for service b filter (latency driven)
tc filter add dev dev parent 1:0 prio 2 u32 match ip src x.x.x.x/32 flowid 21:1
# example for service a filter
tc filter add dev dev parent 1:0 prio 2 u32 match ip src x.x.x.x/32 flowid 21:2
ベストアンサー1
長い間、このようなことをしたことがありませんでした。私の答えを冷笑的に受け入れなさい。
フィルタの親はおそらくPRIO qdisc自体でなければなりません（したがってHTBフィルタとPRIOフィルタがあります...）。それ以外の場合、PRIOはpriomapに基づいてパケット自体を再分類できます。
これが私の古いスクリプトの外観です（FairNAT、GitHubですべてを見つけることができます）。当時はうまくいったと確信しています...この場合、パケットはIPでフィルタリングされていませんが、iptablesでフラグが立てられました。 IPフィルタが信頼できないと思われる場合は、お試しください。
# Create a prio qdisc with 4 classes. All P2P traffic goes into class 4.
$BIN_TC qdisc add dev $UC_DEV parent 1:$UC_MARK handle $UC_MARK: prio \
bands 4
# Add a filter for IPP2P to this qdisc. The rest depends on TOS.
$BIN_TC filter add dev $UC_DEV parent $UC_MARK: protocol ip \
handle $(($UC_MARK+1)) fw flowid $UC_MARK:4
PRIOほとんどの場合、良い選択ではありません。これは非常に積極的で、他のすべてのトラフィックを完全に消費する可能性があります。
HTBクラスが1つしかないと、目的の結果が得られない可能性があります。 10GEに制限されているのも私には少し奇妙に聞こえます。これが理論的なリンク速度であり、実際に達成されていない場合は何もしません。
HFSCこれに適している可能性があります。文書化はHTBよりはるかに悪いです。ただし、速度制限と優先順位の指定はうまく機能します（HTBはどれにも優先順位を指定しません）。