Linux QoS：U32フィルター

Linuxカーネルトラフィック制御サブシステムのU32フィルターは単純で簡単であると考えられているため、詳細なドキュメントは必要ありません。 たとえば、LARTC（Linux Advanced Routing and Traffic Control）には、それに関するいくつかの段落しかありません。 しかし、実際には、U32ははるかに複雑で興味深いものですが、見た目ほど簡単に使用できるわけではありません。 catの下には、使用例と詳細な説明を含むこのフィルターに関する記事があります。

マッピング

したがって、U32フィルターの主な機能は、パケットからデータのブロックを取得し、指定された値と比較することです。 値が一致すると、パッケージに対していくつかのアクションが実行されます。 パッケージ内のデータブロックは、次のパラメーターによって指定されます。

• データブロックのサイズ。 パラメータu32 / u16 / u8によって決定されます。 直観的には、数字はビット単位のブロックの長さです。 カーネルは32ビットブロックで動作します。 tcでは、ブロック長を8、16、32ビットに設定できます。
• ビットマスク。 これは、データブロック全体ではなく、個々のビットのみをチェックする必要がある場合に必要です。 当然、マスクの長さはブロックの長さと一致する必要があります。 ビットごとのAND演算を使用してブロックにマスクが適用され、この演算の結果はすでに設定値と比較されています。
• パケットの開始からのオフセット。 すべてのオフセットは32ビット境界で整列されます。 すべてが見かけほど明白ではないため、これについては後で説明しますが、今のところはこの単純化で十分です。 ほとんどの場合、ゼロのオフセットは、ネットワーク層ヘッダーの先頭に対応します。 IPv4 / IPv6パケットの先頭。

たとえば、次のtcコマンドの例を見てください。

tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ u32 \ match u32 0xc0a80100 0xffffff00 at 12 \ classid 1:8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

優先度10のタイプu32のフィルターを、eth0の規律1：0に追加します。 比較が成功すると、パッケージはクラス1に分類されます。8。 7行目は特に興味深いので、詳細に検討します。

• match u32-一致条件の開始とパケットから取得するデータブロックのサイズを設定します。
• 0xc0a80100は、パケットのビットを比較する値です。
• 0xffffff00は、パケットのデータにスーパーインポーズされるビットマスクであり、結果はすでに設定したものと比較されます。 値とマスクされたデータブロックが等しい場合、特定のアクションが実行されます。 ほとんどの場合、このアクションはパッケージの分類になります。
• at 12-データブロックの先頭が位置する先頭からのオフセット。 このパラメーターが指定されていない場合、オフセットはゼロと見なされます。 フィルターの最初の部分では、ゼロ境界はIPv4などのネットワークレイヤーヘッダーの始まりと見なされます。 負のオフセットも可能です。

これらの手順では、ソースアドレスを確認し（IPv4ヘッダーの形式を見ると確認できます）、それが192.168.1.0/24サブネットに属している場合、パケットを1：8クラスに送信します。 もちろん、RFCを絶えず掘り下げることは面倒であり、すべてのバイアスを念頭に置くことは困難です。そのため、tcはよく使用されるケースに構文糖衣を提供します。 たとえば、次のように記述した場合、この例はより明確になります。

 tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ u32 \ match ip src 192.168.1.0/24 \ classid 1:8
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

1つのコマンドで複数の「一致」パラメーターを指定でき、すべての条件が満たされた場合にのみ一致が成功します。 送信元アドレスが192.168.1.0/24で、ToS値が0x10（インタラクティブトラフィック）であるすべてのパケットをクラス1：1：に送信しましょう。

 tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ u32 \ match ip src 192.168.1.0/24 \ match ip tos 0x10 0x1e \ classid 1:1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すべてが正常に機能するかどうかを確認します。

 #   ~$ tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 1911 success 0) match c0a80100/ffffff00 at 12 (success 0 ) match 00100000/001e0000 at 0 (success 0 ) #   -p,  tc     #   ,   -  ~$ tc -s -pf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 3413 success 0) match IP src 192.168.1.0/24 (success 0 ) (success 0 ) # -       ToS $ ping -f -I 192.168.1.1 -Q 0x10 www.ya.ru PING ya.ru (93.158.134.3) from 192.168.1.1 : 56(84) bytes of data. --- ya.ru ping statistics --- 107 packets transmitted, 107 received, 0% packet loss, time 619ms rtt min/avg/max/mdev = 4.492/5.240/7.560/0.536 ms, ipg/ewma 5.842/5.403 ms #,      ~$ tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 354903 success 107) match c0a80100/ffffff00 at 12 (success 107 ) match 00100000/001e0000 at 0 (success 107 )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、すべてが正常に機能します。パッケージは目的のクラスになります。 しかし、tcの出力を注意深く見ると、いくつかの点がまだ不明です。 たとえば、これらの不可解なfh値は800 :: 800です。 これらは、いわゆるハンドル（英語の「ハンドル」からのトレース）-U32内のフィルター識別子です。



個々のフィルターの各ハンドルは、3つの16進数で構成され、インターフェイスのU32フィルタースペース内で一意です。 私たちの場合、これはハンドル800 :: 800です。 ここで、最後の数字（追加されたフィルターの番号）のみに関心があります。 指定しない場合、システム自体がそれを割り当てます-最も古いものの次、0x800から開始します。 フィルター番号の範囲は0x001〜0xfffです。 適切なパラメーターを使用して、フィルター番号を手動で指定できます。

 tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ match ip src 192.168.1.0/24 \ match ip tos 0x10 0x1e \ classid 1:1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

フィルタは番号順に実行されます。

バインディング

2つのフィルターを追加しましょう。

 tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ match ip src 192.168.1.0/24 \ match ip tos 0x10 0x1e \ classid 1:1 tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::2 \ u32 \ match ip src 192.168.1.0/24 \ match ip tos 0x08 0x1e \ classid 1:2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

両方のフィルターには、同じプレフィックス（ハンドルの最初の2つの数字（800：0））が付きます。 番号-ハンドルの最後の番号の順にそれらを書き留めると想像すると、フィルターのリストが得られます：

 800：0リスト：
 :: 1-ip src 192.168.1.0/24 tos 0x10-> classid 1：1
 :: 2-ip src 192.168.1.0/24 tos 0x08-> classid 1：2

1つのリストのフィルターでは、ハンドルは最後の数字でのみ異なるため、リスト自体は、ハンドルの最初の2つの数字-プレフィックス（800：0）で識別できます。 前述のように、フィルターは従う順序で実行されます。 いずれかのフィルターで一致が成功した場合、何らかのアクションが実行され、U32が終了します。 リストの最後に到達し、一致するものを1つも受信していない場合、U32フィルターは未分類のパケットを先頭に返します。







分類に加えて、アクションは、パッケージをチェックするための別のフィルターリストへの移行になります。 これは、次のように、「classid」ではなく「link」パラメータを使用して行われます（「classid」パラメータが指定されていても無視されます）。

 tc filter add \ dev eth0 \ parent 1: \ prio 10 \ protocol ip \ handle ::2 \ u32 \ match ip src 192.168.1.0/24 \ link 1:
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パケットにサブネット192.168.1.0/24からの送信元アドレスがある場合、1のハンドルでフィルターリストのチェックが開始されます：0。 成功した比較がない場合、前のリスト800：0に戻り、チェックを続けます。 同様に、1：0リストからのフィルターは他のリストに、また3番目などのリストに遷移できます。 そのため、最大7つの遷移（これでは不十分な場合、カーネルソースのマクロ置換TC_U32_MAXDEPTHを変更できます）。







また、多数のフィルターを多数のリストに分割し、そのようなトランジションを平均的に整理することは、1つの大きなリストに対してチェックするよりもはるかに高速ではないことを考慮に入れる必要があります。 ただし、原則として、バインディングは別のU32メカニズム（ハッシュ）と組み合わせて使用​​されます。

ハッシング

その前に、フィルターリストを見ました。 しかし実際には、それらはハッシュテーブルと呼ばれるより大きな構造の一部にすぎません。 この場合、ハッシュテーブルはセルの1次元配列（バケットの英語配列）であり、それぞれに1つのフィルターリストが格納されます。



ハンドルでは、最初の番号だけがハッシュテーブル番号であり、2番目はセル番号です。 ハッシュテーブル番号の範囲は0x000〜0xfffで、セル番号の範囲は0x00〜0xffです。 セルの数は1〜256で、2の累乗でなければなりません（別の値を設定することはできません-tcはエラーメッセージを表示します）。 番号0x800のハッシュテーブルはルートと呼ばれ、1つのセルで構成され、自動的に作成されます。 パッケージチェックは、常にセル800のリストを調べることから始まります：0。



次のような追加のハッシュテーブルを作成できます。

 tc filter add \ dev eth0 \ parent 1: pref 10 \ protocol ip \ handle 1: \ u32 divisor 1
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、「ハンドル1：」はハッシュテーブルの番号を設定し、「除数1」-その中のセルの数（この場合、番号1のハッシュテーブルには、フィルターリスト1：0が配置されるセルが1つだけあります）。



リストのジャンプを使用して、ソースアドレスとToSフィールドによる分類で例を拡張します。

 #   prio     ~$ tc q add \ dev eth0 \ root \ est 0.1s 10s \ handle 1: \ prio bands 8 # - 1:    ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle 1: \ u32 \ divisor 1 #   -  ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ match ip src 192.168.1.0/24 \ link 1: #    ToS  - 1: ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ ht 1: \ match ip tos 0x08 0x1e \ classid 1:3 ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::2 \ u32 \ ht 1: \ match ip tos 0x10 0x1e \ classid 1:1 # ,  ,      #,     ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::2 \ u32 \ match ip src 192.168.1.0/24 \ classid 1:7 #   ~$ tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 1::1 order 1 key ht 1 bkt 0 flowid 1:3 (rule hit 0 success 0) match 00080000/001e0000 at 0 (success 0 ) filter parent 1: protocol ip pref 10 u32 fh 1::2 order 2 key ht 1 bkt 0 flowid 1:1 (rule hit 0 success 0) match 00100000/001e0000 at 0 (success 0 ) filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 link 1: (rule hit 33900 success 0) match c0a80100/ffffff00 at 12 (success 0 ) filter parent 1: protocol ip pref 10 u32 fh 800::2 order 2 key ht 800 bkt 0 flowid 1:7 (rule hit 3583 success 0) match c0a80100/ffffff00 at 12 (success 0 ) #   ,      #ToS   192.168.1.0/24,      ~$ ping -fc10 -I 192.168.1.1 -Q 0x08 8.8.8.8 ~$ ping -fc15 -I 192.168.1.1 -Q 0x10 www.kernel.org ~$ ping -fc25 -I 192.168.1.1 -Q 0xaa www.habrahabr.ru #    ~$ tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 1::1 order 1 key ht 1 bkt 0 flowid 1:3 (rule hit 50 success 10) match 00080000/001e0000 at 0 (success 10 ) filter parent 1: protocol ip pref 10 u32 fh 1::2 order 2 key ht 1 bkt 0 flowid 1:1 (rule hit 40 success 15) match 00100000/001e0000 at 0 (success 15 ) filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 link 1: (rule hit 578192 success 0) match c0a80100/ffffff00 at 12 (success 50 ) filter parent 1: protocol ip pref 10 u32 fh 800::2 order 2 key ht 800 bkt 0 flowid 1:7 (rule hit 547850 success 25) match c0a80100/ffffff00 at 12 (success 25 )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、「リンク」パラメーターを使用すると、セル番号0にあるフィルターリストにのみ移動できます。それでは、他のセルのリストをどのように確認できますか？ これを行うには、hashkeyパラメーターとハッシュメカニズムが使用されます。 U32でのハッシュの意味は、システムがパケットのデータに基づいてリストにセルの番号を受け取ることです。 これは、チェックの回数を減らすために必要です。 表示時間はリスト内のフィルターの数に線形に依存するリストとは異なり、ハッシュは一定時間（さらに非常に短い時間）実行されます。 多数のフィルターを使用して、ハッシュを使用すると、リストと遷移のみを使用するよりも桁違いに高いパフォーマンスを実現できます。







ハッシュを使用して前の例を書き直します。

 # -   1:  32  ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle 1: \ u32 \ divisor 32 #        ToS ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle 1:08:1 \ u32 \ ht 1:08 \ match u32 0 0 \ classid 1:3 ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle 1:10:1 \ u32 \ ht 1:10 \ match u32 0 0 \ classid 1:1 #     192.168.1.0/24  #   - 1:      ToS ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::1 \ u32 \ match ip src 192.168.1.0/24 \ link 1: \ hashkey mask 0x001f0000 at 0 #   ,    #     ~$ tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle ::2 \ u32 \ match ip src 192.168.1.0/24 \ classid 1:7 #     ToS ~$ ping -fc10 -I 192.168.1.1 -Q 0x08 8.8.8.8 ~$ ping -fc30 -I 192.168.1.1 -Q 0x10 www.kernel.org ~$ ping -fc50 -I 192.168.1.1 -Q 0xaa www.habrahabr.ru #     ~$ tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 32 filter parent 1: protocol ip pref 10 u32 fh 1:8:1 order 1 key ht 1 bkt 8 flowid 1:3 (rule hit 10 success 10) match 00000000/00000000 at 0 (success 10 ) filter parent 1: protocol ip pref 10 u32 fh 1:10:1 order 1 key ht 1 bkt 10 flowid 1:1 (rule hit 30 success 30) match 00000000/00000000 at 0 (success 30 ) filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 link 1: (rule hit 30135 success 0) match c0a80100/ffffff00 at 12 (success 90 ) hash mask 001f0000 at 0 filter parent 1: protocol ip pref 10 u32 fh 800::2 order 2 key ht 800 bkt 0 flowid 1:7 (rule hit 27250 success 50) match c0a80100/ffffff00 at 12 (success 50 )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例のハッシュアルゴリズムを検討してください。 このアルゴリズムはカーネルバージョン2.6で導入され、まだ変更されていません（カーネルバージョン2.4ではアルゴリズムが異なります）。

• 「ハッシュキー」パラメータで指定された「アット」オフセットで32ビットワードを取得します。 オフセットはゼロなので、IPパケットの最初の32ビットが取得されます。
• 同じパラメーターからビットマスクを適用します。 ビットマスクは「0x001f0000」で、ToSフィールドの位置に対応しています。
• 結果を最下位ビットの方向にnビットだけシフトします。 nの値はマスクから計算され、その中の最下位ゼロビットの数に等しくなります。 マスクでは、最下位ゼロビットの数は16です。これは、マスクされたダブルワードがこれらの16ビットだけシフトされることを意味します。 その後、ToS値が下5桁に表示されます。
• 結果の値に0xffマスクを適用します。 この場合、何も変更されません。 他の場合、これはマイナーを除くすべてのオクテットをリセットします。
• 最後に、ターゲットテーブルのセル数が256未満の場合、結果に数値kに等しいビットマスクが重ねられます。 kの値は、移行先のハッシュテーブルのセルよりも1つ小さくなります。 ターゲットテーブルには32個のセルがあります。つまり、kの値は31になります。このマスクを適用すると、結果はセルの数以下になることが保証されます。

残念ながら、この場合、tcはオフセットの書き込みを単純化する手段を提供しないため、「hashkey ip tos」のようなものを書き込むことはできません。 もう1つの難点は、フィルターを配置する名前ボックスを決定することです。 方法は1つしかありません-手動でハッシュを読み取る方法（tcには、「sample」パラメーターがあり、目的のセルにフィルターを配置するためにハッシュを自動的に計算できますが、ハッシュアルゴリズムはカーネル2.4およびそれ以降のカーネルにはまだ適していません）

オフセット

ヘッダーの長さが固定されていれば、すべてが単純になります。 しかし、残念ながら、これはそうではありません-ヘッダーには追加のオプション要素があり、次のレベルのヘッダーのフィールドを比較することが非常に難しくなります。 幸いなことに、U32はこれも提供します。 この関数は「ヘッダーオフセット」と呼ばれ、パッケージ自体から次のヘッダーのオフセットを見つけるように設計されています。



しかし、最初に、U32フィルターの2つの新しい概念を理解しましょう。定数オフセット（簡潔にするために「permoff」と指定します）と一時的な変位（「tempoff」と指定します）です。 permoff値は、「link」パラメーターを使用して行われる次の遷移およびそれ以降の遷移中にすべてのオフセットに常に追加され、新しいpermoffおよびtempoff値の計算に使用されます。 キーワード「nexthdr +」がパラメーターで使用され、それ以上の移行の影響を受けない場合、tempoff値は次の移行中にのみ指定されたオフセットに追加されます。 前のリストに戻ると、値はロールバックされます。



小さな仮説的な例を考えてみましょう。 リスト1：0を実行するときにpermoffをゼロにすると、一致が成功します。 リスト2の実行に進むと、新しいpermoff値は20に等しくなります。 この場合、値20は、2：5リストのフィルターに示されているすべてのオフセットに追加されます2：2：5リストで、3：12リストへの遷移との別の一致があり、定数オフセットが8に変更されると、新しいそして、permoff値は28になります。リスト3:12を実行すると、値28はすべてのオフセットに既に追加されます。リスト3:12に成功した比較がない場合、U32はリスト2：5に戻り、permoffは再び20になります。そして成功した比較はありません、そしてリスト1に戻ります：0、それからpermoffは再び等しくなります ヌルゼロ。 実際、ゼロマークを単純にシフトし、それに対してオフセットをさらに示します。 permoffとtempoffの値は、最初はゼロです。



RFCを見て、IPv4ヘッダー形式を見てください。 幸いなことに、このフィールドには特別なフィールドがあり、その値はダブルワードでのタイトルの長さと同じです。 そして、そのためにこの情報を使用できます。 次のレベルのヘッダーの位置を計算します。



これは次のように行われます。

 tc filter add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ u32 \ match ip src 192.168.1.0/24 \ match protocol 0x01 0xff \ link 1: \ offset at 0 mask 0x0f00 shift 6 plus 0 eat
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の行と何が起こるかを詳しく考えてみましょう：

• offset-マッチングが成功したときにpermoffまたはtempoffの値を変更していることを示します。
• 「at」パラメータで指定されたオフセットで単一の単語が取得されます。 私たちの場合、これはゼロであるため、パケットの最初の16ビットが取得されます。 「at」パラメータの値は2の倍数に減少します。
• ビットマスクは、パケットから受信した値に重畳されます。 これは、IPv4ヘッダー長フィールドの位置に対応する0x0f00に等しくなります。 このフィールドに値5（バイナリ表現0101）があるとします。 バイナリ形式では、以前の操作の結果は「0000.0101.0000.0000」に等しくなります。
• IPヘッダー長フィールドの値は、ダブルワードで表したヘッダーの長さと等しいことがわかっています。 そのため、取得した値を何らかの方法でバイトに変換する必要があります。 その結果、必要なビットがさらにオフセットされるため、問題は複雑です。 下位オクテットに表示されるように値をシフトします。下位ビットに8ビットシフトし、「0000.0000.0000.0101」を取得します。 見出しのサイズはダブルワードで示されているため、ここで4を掛けます。 乗算は、上位ビットの方向に2ビットシフトすることで置き換えられます。 シフト後、「0000.0000.0001.0100」が得られます。 適切な値を取得しました。 両方のシフト操作を1つに結合します。 その結果、ヘッダーの長さをバイト単位で取得するには、マスクされた初期値を最下位ビットの方向に6ビットシフトする必要があります。 これは、「shift」パラメーターを使用して行われます。 すべての操作の後、値は20になりました。
• plusパラメーターの値は、取得した値に追加されます。 私たちの場合、これは0なので、何も追加されません。 このパラメーターを指定することさえできませんでした。
• eatパラメーターは、計算された値がpermoff値に追加されることを示しています。 それ以外の場合、tempoff値が計算されます。
• その結果、1：0リストからフィルターをチェックするとき、ゼロオフセットは次のヘッダーの先頭に対応し、一致するICMPヘッダーフィールドに基づいてフィルターを構築できます。たとえば、メッセージタイプ値をチェックします。 tempoff値を変更する場合は、「nexthdr +」キーワードを使用してオフセットを指定し、着信リストで明示的に指定する必要があります。

その後、ICMPメッセージタイプが1：0リストに一致するフィルターを追加できます。 たとえば、タイプEcho-RequestのICMPパケットはクラス1に送信されます。8。

 ~$tc f add \ dev eth0 \ parent 1: \ pref 10 \ protocol ip \ handle 1::1 \ u32 \ ht 1: \ match u8 0x08 0xff \ classid 1:8 #    ~$ sudo tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 1::1 order 1 key ht 1 bkt 0 flowid 1:8 (rule hit 0 success 0) match 08000000/ff000000 at 0 (success 0 ) filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 link 1: (rule hit 48553 success 0) match c0a80100/ffffff00 at 12 (success 0 ) match 00010000/00ff0000 at 8 (success 0 ) offset 0f00>>6 at 0 eat #  - ~$ ping -fc5 -I 192.168.1.1 www.ixbt.com #      ~$ tc -sf ls dev eth0 filter parent 1: protocol ip pref 10 u32 filter parent 1: protocol ip pref 10 u32 fh 1: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 1::1 order 1 key ht 1 bkt 0 flowid 1:8 (rule hit 5 success 5) match 08000000/ff000000 at 0 (success 5 ) filter parent 1: protocol ip pref 10 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 10 u32 fh 800::1 order 1 key ht 800 bkt 0 link 1: (rule hit 149972 success 0) match c0a80100/ffffff00 at 12 (success 5 ) match 00010000/00ff0000 at 8 (success 5 ) offset 0f00>>6 at 0 eat
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

それだけです。オリジナルには、さらに詳しい情報があります-ドライガイドと比較のリスト（同じ構文の砂糖）。



オリジナル-u32フィルター。-残念ながら、著者は私には知られていないが、すべてがラッセル・スチュワートを指している。