タグ付けされた質問 「traffic-shaping」

HFSCに関するオリジナルのSIGCOMM '97 PostScript論文を読みましたが、これは非常に技術的なものですが、基本的な概念は理解しています。ほぼすべての他のスケジューリングアルゴリズムと同様に、線形のサービスカーブを与える代わりに、凸または凹のサービスカーブを指定することができます。したがって、帯域幅と遅延を分離することができます。ただし、このペーパーでは使用されているスケジューリングアルゴリズムの種類（リアルタイムおよびリンク共有）に言及していますが、スケジューリングクラスごとに1つの曲線のみに言及しています（この曲線を指定することで分離が行われ、そのために必要な曲線は1つだけです） ）。 現在、HFSCはALTQスケジューリングフレームワークを使用してBSD（OpenBSD、FreeBSDなど）に実装され、TCスケジューリングフレームワーク（iproute2の一部）を使用してLinuxに実装されています。どちらの実装であった二つの追加サービスカーブ、コメントを追加しないで、元の論文では！リアルタイムのサービス曲線と上限のサービス曲線。繰り返しになりますが、元の論文では2つのスケジューリングアルゴリズム（リアルタイムとリンク共有）に言及していますが、その論文ではどちらも1つのサービスカーブで機能します。現在BSDとLinuxで見られるように、いずれか1つに対して2つの独立したサービス曲線はありませんでした。 さらに悪いことに、ALTQの一部のバージョンは、HSFCにキューの優先順位を追加するようです（元の論文にも優先順位などはありません）。いくつかのBSD HowToがこの優先度設定について言及しているのを見つけました（最新のALTQリリースのマニュアルページはHSFCのそのようなパラメーターを知らないので、公式には存在しません）。 これにより、HFSCのスケジューリングは元の論文で説明されているアルゴリズムよりもさらに複雑になります。また、インターネット上には、しばしば矛盾するチュートリアルがたくさんあります。これがおそらく、HFSCスケジューリングが実際にどのように機能するかを誰も理解していないように見える主な理由です。質問をする前に、何らかのサンプルセットアップが必要です。次の画像に示すように、非常に単純なものを使用します。 代替テキストhttp://f.imagehost.org/0177/hfsc-test-setup.png チュートリアルが互いに矛盾しているため、私が答えることができないいくつかの質問があります： リアルタイムカーブが必要なのは何ですか？A1、A2、B1、B2がすべて128 kbit / sリンク共有であると仮定すると（どちらもリアルタイムカーブなし）、ルートに配布する512 kbit / sがある場合、それぞれが128 kbit / sを取得します（そしてAとBは両方とももちろん256 kbit / sです）。A1とB1に128 kbit / sのリアルタイムカーブを追加するのはなぜですか？これは何に役立つでしょうか？これら2つに高い優先度を与えるには？元の論文によると、カーブを使用することで優先順位を高くすることができます。両方のクラスに[256kbit / s 20ms 128kbit / s]の曲線を与えると、両方とも自動的にA2とB2の2倍の優先度を持ちます（平均で128 kbit / sしか得られません） リアルタイム帯域幅はリンク共有帯域幅にカウントされますか？たとえば、A1とB1の両方に64kbit / sのリアルタイムと64kbit / sのリンク共有帯域幅しかない場合、リアルタイムで64kbit / sが提供されると、リンク共有要件も満たされることを意味します（余分な帯域幅を取得しますが、それをしばらく無視します）、またはリンク共有を介して別の64 kbit / sを取得することを意味しますか？それで、各クラスには、リアルタイムとリンクシェアの帯域幅の「要件」がありますか？または、リンク共有曲線がリアルタイム曲線よりも高い場合、クラスの要件はリアルタイム曲線よりも高いだけですか（現在のリンク共有要件は、指定されたリンク共有要件からこれに既に提供されているリアルタイム帯域幅を引いたものに等しい）クラス）？ 上限曲線はリアルタイムにも、リンク共有のみに適用されますか、それとも両方に適用されますか？一部のチュートリアルでは、一方の言い方があり、一部は、他の方法で言います。上限がリアルタイム帯域幅+リンク共有帯域幅の最大値であると主張する人もいますか？真実は何？ A2とB2が両方とも128 kbit / sであると仮定すると、A1とB1が128 …

35 linux  qos  traffic-shaping  bsd  traffic-management 

私が使用しているHTB構造については疑問があります。 私の目的は、ローカルネットワークのユーザーのダウンロードとアップロードの速度を制限することです。ネットワークの各ユーザーには、ドメインの個人用リストがあり、ドメインの速度は上下できません。 つまり、user1はslashdot.orgでのアクセスをダウンロードで8KB、アップロードで3KBに制限でき、user2はslashdot.orgでのアクセスを4KBから1KBに制限できます。 現時点では、うまく機能するiptables / tcカップルをセットアップしますが、非常に小さな規模で、同時に2つまたは3つの仮想ホストを使用します（残念ながら、実際のサイズテストは実行できません）。 現在の構造は次のとおりです（LANの出口にあるもののみを表示します。アップロード用のものは、単にこの「コピー」です） インターフェイスにアタッチされたHTB qdisc（ハンドル2 :)、デフォルトのトラフィッククラスはクラスFFFFです。 HTB qdiscの直下にあるルートクラス2：1は、DOWNLINKキャパシティのレートと上限を持っています。 2：1の子としてのデフォルトクラス2：FFFF。レートは1kbspで、上限はDOWNLINK容量です。 次に、特定のドメインのユーザーに新しい制限がある場合、他のクラスが動的に追加され、そのドメインからのダウンロード速度を制御するために新しいtcクラスが追加されます。 今のところ、私がやったことは次のとおりです。 一意のIDを持つ新しいtcクラスを作成します（ここではポイントではなく、データベースから取得します）。クラス2：1の親として、レート値は1bps、ceil値は制限されたダウンロード速度に設定されます。 tcコマンドは次のとおりです。 -------------- BEGIN SCRIPT -------------- DOWNLINK=800 ## Setting up the static tc qdisc and class $tc qdisc add dev $LAN_IFACE root handle 2: htb default 0xFFFF # Main class so the default class can …

29 linux  traffic-shaping  iptables  htb 

ここに書かれているように、Linuxゲートウェイでトラフィックシェーピングを設定しようとしています。複数のLANインターフェイスがあるため、スクリプトをカスタマイズする必要があります。LAN側を形成するために、次のようなifb疑似デバイスを作成する予定です。 modprobe ifb ip link set dev ifb0 up /sbin/tc qdisc add dev $WAN_INTERFACE ingress /sbin/tc filter add dev $WAN_INTERFACE parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 上記の要点リポジトリのスクリプトには、次の行があります。 /sbin/tc qdisc add dev $WAN_INTERFACE handle ffff: ingress /sbin/tc filter add dev $WAN_INTERFACE parent …

20 traffic-shaping  tc 

tcとnetemを使うのは初めてです。特定のIPアドレスに送信されるパケットを遅延させたい。ただし、次のコマンドにより、IPアドレス1.2.3.4だけではなく、システム上のすべてのパケットが遅延します。 tc qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1: prio tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 500ms tc filter add dev eth0 parent 1:0 protocol ip pref 55 handle ::55 u32 match ip dst 1.2.3.4 flowid 2:1 私の推測では、残りのすべてのトラフィックがnetemを通過しないように指定するには、最後に何らかのキャッチオールフィルターが必要です。しかし、何も機能しません。これをどのように機能させるのですか？

20 linux  traffic-shaping  tc 

透過的なプロキシ設定があります。Linuxでトラフィックシェーピングを探してみましたが、オンラインで見つけることができたのは、インターフェイス（eth0 / eth1 ...）によってトラフィックを制限することだけでした。 IPアドレスまたはIP範囲で帯域幅を制限する必要があります（特定の制限を超えないようにします）。その方法は見つかりません。 それを行う方法はありますか？

15 linux  ip  traffic-shaping  ip-address 

一部のISPが行うのと同様に、帯域幅の使用量を調整する必要があるため、数秒後に速度が低下します。

14 iptables  traffic-shaping  bandwidth-control 

ハッシュフィルタリングを備えた、Linuxブリッジで構築された素晴らしいシェーパーがあります。要するに、br0接続externalとinternal物理インターフェース、VLANタグ付きパケットは「透過的に」ブリッジされます（つまり、VLANインターフェースはありません）。 現在、異なるカーネルは異なる方法でそれを行います。正確なカーネルバージョンの範囲が間違っている可能性がありますが、ご容赦ください。ありがとう。 2.6.26 したがって、debianでは、2.6.26以降（2.6.32まで、私は信じています）---これは動作します： tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \ u32 ht 1:64 match ip dst 192.168.1.100 flowid 1:200 ここで、「カーネル」は0x8100の「プロトコル」フィールドの2バイトに一致しますが、IPパケットの先頭を「ゼロ位置」としてカウントします（少し不明瞭な場合は英語でごめんなさい）。 2.6.32 繰り返しますが、debian（私はバニラカーネルを構築していません）では、2.6.32-5 ---これは動作します： tc filter add dev internal protocol 802.1q parent 1:0 prio 100 \ u32 ht 1:64 match ip dst 192.168.1.100 at 20 …

12 vlan  linux-networking  traffic-shaping  linux-kernel  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ユーザーですべての人に十分なはずです」シナリオに行かないことを願っています...）

12 linux  networking  isp  traffic-shaping  tc 

着信トラフィックのレート制限が可能かどうか、私はまったく理解していません。リモートサーバーのパケット送信レートを制御する直接的な方法はありません（両方のエンドポイントを制御している場合を除きます）が、この制限を考慮すると、ダウンロードマネージャーを使用してダウンロード速度の制限を正しく設定する方法？ TCPスロースタートとレート制限着信トラフィックの間にリンクはありますか？slow-startで説明されている方法を使用して、送信者のパケット送信レートを人為的に制限することは可能ですか？ 追加の考慮事項として、トラフィックシェーピングを実装するサーバーがPPPoE接続自体を確立し、残りのネットワークのルーターとして機能することに注意してください。 更新：これまでの回答は、私が尋ねた質問の公正な概要を示しましたが、ダウンロードマネージャーが着信トラフィックを制限する方法、さらに具体的には、同様の戦略を実装できるかどうかはまだわかりませんLinuxゲートウェイボックス。

12 linux  networking  bandwidth  traffic-shaping 

次の状況：私たちは、地元の居住者ホールのインターネット接続を管理する学生のグループであり、合計で約2000人のエンドユーザーがいます。 トラフィックポイントシステムがあり、MBごとにダウンポイントまたはアップロードコストポイントがあり、新しいポイントは1時間ごとに追加されます。現時点では、ユーザーがすべてのポイントを費やしたとき（DebianゲートウェイルーターのiptablesのREJECTポリシーにユーザーを配置することにより）ユーザーのインターネットアクセスをブロックします。 ユーザーの帯域幅を制限したいだけです。これを行う最良の方法は何ですか？ 簡単な答えは、ユーザーのスイッチポート（主にCisco Catalyst 3550）にレート制限を設定することです。ただし、これは望ましくありません。当社のネットワーク内および大学のネットワークへのトラフィックは無制限のままである必要があるためです。Cisco IOSで特定の宛先または送信元IP範囲（つまり、出力と入力の両方）を持つパケットに対してのみ帯域幅を制限する方法はありますか？何も見つかりませんでした。 もう1つの方法は、ゲートウェイルーター上のトラフィックを制御することです。いくつかの解決策が思い浮かびます。 tcまたはtcng-どちらもかなり難解な構文を持ち、IPごとのトラフィック制御を行うための優れた機能を提供しないようです。非常に多くの人々に専用のQDiscを使用すると、おそらくルーターの速度が大幅に低下します。さらに、両方のドキュメントはかなり時代遅れです。 shorewall-構成にはかなりきちんとした構文があるようですが、この量のトラフィックとユーザーを処理できるかどうか、およびIPごとのトラフィック制限に適しているかどうかはわかりません pfSense-私たちのような目的のために意図されたOSのように見えます。ただし、ゲートウェイルーターを完全に再インストールする必要があります。他のBSDシステムはなく、pfSenseには非常に優れたトラフィックアカウンティング機能が必要です（現時点ではfprobe-ulogとulog-acctdを使用しています）。 あなたの経験は？どのソリューションが私たちのニーズに合い、最も簡単に保守できますか？他にアイデアはありますか？ システムに関する追加情報が必要な場合は、お気軽にお問い合わせください。 前もって感謝します。 編集：私はシステムを実装しているiptablesとtc。 すべてのユーザーは、/ 28-subnet、VPN IP（両方とも10.0.0.0/8から）、および外部IPを持ち、すべて1つのiptablesチェーンを介して操作されます。このチェーンには、単純なルールが1つだけありRETURNます。 5分ごとに、Pythonスクリプトがこれらのルールのバイトカウンターを読み取ります。PostgreSQLデータベースのカウンターをリセットし、ユーザーのトラフィックポイントアカウントを更新します。 ユーザーのポイントバランスが特定のしきい値を下回った場合、このユーザーに対して2つのtcクラス（ゲートウェイルーターの受信用、送信インターフェイス用）が作成され、これらのクラスに属するtcフィルターにIPが入力されます。クラスはHTBによって速度制限されています。 以前のシステムと比較してfprobe-ulog、ulog-acctdこれはバイトカウントがiptablesによって行われるため、はるかに高速です。 ユーザーのネットワーク速度が大幅に向上しました。

11 linux  networking  cisco  iptables  traffic-shaping 

1024以上の外部IPがたくさんあるサーバーがあるとします。ユーザーが大量のトラフィックを引き起こしていますが、すべてではありません。すべての帯域幅を消費するものは少なく、他の帯域幅をすべて消費するため、インターネット速度が低下します。 私たちは、全員が満足するか、または少なくとも過半数が満足するように、シェーピングルールを実装することを考えており、そのための最善のアプローチについて議論しています。 最初の計画 ログオンしているクライアントの数を把握し、帯域幅をクライアント間で分割して、全員に同じケーキを食べさせます。 利点： 帯域幅に多額の料金を支払いません 誰も法律を破っていない 短所 帯域幅は均等に分割され、帯域幅のニーズが低いユーザー（論文を読む、Facebookを読むなど）は、ビジネスで私のサービスに依存するヘビーユーザーと同じ帯域幅になります。 すべてのユーザーは同じ帯域幅を使用しますが、ニーズが低いユーザーはすべてを必要としない場合でも共有を「投獄」するため、多くの帯域幅が使用されないままになります 第二計画 ユーザーを監視し、ユーザーが帯域幅制限に達しているか、それを超えているか（サーバーの合計制限）を確認します。そのポイントに達した場合は、ユーザーが何を最も多く食べているかを特定します。総帯域幅の40％-50％以上を食べているユーザーを見つけたら、20分間刑務所に送ります。刑務所とは、たとえば帯域幅を250kb / sに下げることを意味します。 利点： 帯域幅が無駄にならない 帯域幅が無駄にならない場合、重要なユーザーは帯域幅をより多く使用でき、私は幸せなクライアントを持っています よりインテリジェントなソリューションであり、誰もがニーズに基づいて拡張できる 悪者が投獄され、善良な人々（多くの場合は多く）が幸せな社会である帯域幅警察を使用します 短所 負荷の高いサーバー上の監視ツールは、リソースを大量に消費する傾向があるため、サーバーを「スリープ」状態にすることができます 私は悪者はいないかもしれませんが、オンラインの多くの善良な人と帯域幅が制限を超えており、誰を罰するのか分からない状況にあります（この場合、最初の計画を1時間適用することがあります） 少しブレーンストーミングと提案を受け入れる

10 traffic-shaping 

インターネット回線に何らかのトラフィック管理を追加したいと思います。たくさんのドキュメントを読んだ後、HFSCは私には複雑すぎると思います（すべての曲線を理解しているわけではありません。正しく理解できないと思います）。CBQはお勧めしません。基本的にHTBはほとんどの人のために行きます。 私たちの内部ネットワークには3つの「セグメント」があり、それらの間で帯域幅を多かれ少なかれ均等に共有したいと思っています（少なくとも最初は）。さらに、少なくとも3種類のトラフィック（リアルタイムトラフィック、標準トラフィック、バルクトラフィック）に従ってトラフィックを優先する必要があります。帯域幅の共有は、リアルタイムトラフィックを可能な限り常にプレミアムトラフィックとして扱う必要があるという事実ほど重要ではありませんが、他のトラフィッククラスが不足することはありません。 問題は、何がより意味があり、リアルタイムのスループットが向上するかを保証することです。 セグメントごとに1つのクラスを作成し、それぞれが同じレートを持ち（HTB開発者によると、葉ではないクラスでは優先度は関係ありません）、これらの各クラスには、3つの優先度レベル（異なる優先度）の3つのサブクラス（葉）がありますと異なるレート）。 優先度レベルごとに1つのクラスがあり、それぞれに異なるレートがあり（やはり優先度は関係ありません）、セグメントごとに1つずつ、3つのサブクラスがありますが、リアルタイムクラスの3つすべてが一括で最高のプリオ、最低のプリオを持ちますクラスなど。 次のASCIIアートイメージを使用して、これをより明確にするようにします。 Case 1: root --+--> Segment A | +--> High Prio | +--> Normal Prio | +--> Low Prio | +--> Segment B | +--> High Prio | +--> Normal Prio | +--> Low Prio | +--> Segment C +--> High Prio +--> Normal Prio …

10 linux  qos  traffic-shaping  traffic-management  htb 

ネットワークトラフィックを制限するLinuxボックス（Centos 5.5）があります。クライアントに配布するアプリケーションがあり、256Mbit /秒の最小推奨帯域幅でテストしたいと思います。これまでのところ、私が見たtcチュートリアルでは、特定の基準に従って帯域幅を制限できるようですが、すべての状況で（IPヘッダーの外観に関係なく、すべてのIPアドレスとの間で）帯域幅を制限したいと思います。 私が使用することを示唆した1つのチュートリアル： tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2 しかし、私は次のエラーを受け取ります： Unknown filter "flowid", hence option 10:2 is unparsable すべての状況でeth0に出入りする帯域幅を制限する方法に関するアイデアはありますか？

9 linux  traffic-shaping 

私は、外側に10GBeインターフェース、内側に結合されたギガビットイーサネットインターフェースを持つLinuxルーターを持っています。 現在、2GBit / sの予算があります。1か月の平均速度が5％を超えると、10ギガビット/秒の容量全体が課金されます。ドルでかなりのステップアップ。 したがって、これを10GBeインターフェースで2GBit / sに制限したいと思います。 TBFフィルターが理想的かもしれませんが、このコメントは心配です。 Alphaを除くすべてのプラットフォームでは、理想的な最小限のバースト性で最大1mbit / sの通常のトラフィックを形成し、構成されたレートで正確にデータを送信できます。 このレートをインターフェイスに適用するためにTBFまたは他のフィルターを使用する必要がありますか。ここに示されている例が理解できません 。TrafficControl HOWTO 特に「例9. 256kbit / s TBFの作成」 tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0 tc qdisc add dev eth0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps …

8 linux  iptables  routing  traffic-shaping 

1つの小規模オフィスネットワークでBitTorrentおよび類似のピアツーピア（P2P）サービスをどのようにブロックするか、大幅に遅くすることができますか？ Server Faultを検索したところ、これに関する最良の技術的アイデアの結集点として機能する質問を見つけることができませんでした。既存の質問はすべて特定の状況に関するものであり、支配的な回答は本質的に社交的/法的です。これらは有効なアプローチですが、純粋に技術的な議論は多くの人に役立つと思います。ネットワーク上のマシンにアクセスできないとします。 P2Pトラフィックでの暗号化の使用が増加しているため、ステートフルパケットインスペクションはあまり機能しないソリューションになりつつあるようです。私にとって理にかなっていると思われるアイデアの1つは、ヘビーユーザーを送信または受信しているものに関係なく、単にIPでスロットルすることです。しかし、現時点では、多くのルーターがその機能をサポートしていないようです。 P2P / BitTorrentトラフィックをどのように抑制できますか？

8 traffic-shaping  qos  bittorrent