web-dev-qa-db-ja.com

中規模ISPのQoS構成

すべての256KbpsDSLクライアント(すべて同じIP範囲に属する)が単一のQoSルールで200Kbpsの保証速度を取得する構成を実装するのに最適なLinuxベースのQoSプラットフォームは何ですか?

3
MZK

保証と公平な分割のために、HFSCスケジューラー(BSDのaltqからlinuxに移植された)は素晴らしいことです。 (少なくとも、HTBほど不器用でバケツではありません。)残念ながら、Linuxでトラフィックシェーピングを設定することは、残酷な学習曲線を伴う苦痛なプロセスです。また、tcインターフェイスは単に使い勝手が悪いため、MasterShaperなどを使用することをお勧めします。フロントエンド。

(追記:tcを自分で管理する場合は、アップロードのシェーピングにIFBカーネル機能を使用してください。これは前にここで提案したIMQに似ていますが、新しいカーネルで動作し、フレームワーク全体に少しよく適合します)

1
exa

標準のLinuxQoS /トラフィック制御システムは[tc][1](トラフィック制御)と呼ばれます。

チェーンを初期化し、そのプロパティを設定してから、次のようにIPをチェーンに追加する必要があります。

#!/bin/bash
DEV=eth0
PATH=$PATH:/sbin
tc qdisc del dev $DEV root
tc qdisc add dev $DEV root handle 1: htb default 20
tc class add dev $DEV parent 1:1 classid 1:10 htb rate 2000kbps ceil 2000kbps burst 500kb quantum 1500
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip dst 10.10.10.1/24 flowid 1:10
tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 match ip src 10.10.10.1/24 flowid 1:10
1
Caleb

また、前述の構成では、個々のIPごとに個別のルールを設定しなくても、必要な速度の範囲内の各IPが割り当てられますか?

いいえ、ありません。 HTBの動作方法 、個々のIPではなく、バケット全体にレートを割り当てることができます。 Calebが試みたのは、利用可能な帯域幅2000 Kbpsを、SFQ qdiscを介して10人の顧客に均等に分散することでした。ただし、これは期待どおりに機能しません。SFQは接続ごとのスケジューリングを計算します。 IPごとではありません-顧客のいずれかが他の顧客よりも帯域幅を大量に消費する接続を開いている場合、その顧客は合計でより多くの帯域幅を取得します。

[〜#〜] esfq [〜#〜] と呼ばれる別のスケジューラがあります。これはSFQを拡張して、IPごとにスケジュールできるようにしますが、それでもスケジュールするだけです200 kbpsで特定のユーザーを制限せずに、現在アクティブなトラフィック。それを可能にするすぐに利用できるqdiscがあるかどうかはわかりませんが、さまざまなqdiscプロジェクトの膨大な量を考えると、そうだと思います。

もう1つの問題は、tcがインターフェイス上の発信トラフィックのみをスケジュールし、着信トラフィックが考慮されないことです。 中間キューイングデバイス(IMQ) は、この制限を回避するのに役立ちます。

1
the-wabbit
0
dsmsk80

Mikrotik RouterBoards;)あなたが持つことができる最高のプラットフォーム。彼らのOS(RouterOS)はLinuxベースですが、アプリケーションであるため、実際のシェルやファイルシステムにアクセスすることはできません。

ただし、これらは小さなISPプラットフォームであるため、非常に気に入っています。

0
TomTom