Minimalna szybkość i domyślny problem klasy dla HTB


29

Mam wątpliwości co do struktury HTB, której używam.

Moim celem jest ograniczenie prędkości pobierania i wysyłania użytkowników w sieci lokalnej. Każdy użytkownik sieci ma osobistą listę domen z prędkością rosnącą i malejącą dla domeny, której nie może przekroczyć.

Oznacza to, że użytkownik 1 może mieć ograniczony dostęp do slashdot.org do 8 KB przy pobieraniu i 3 KB do przesłania, a użytkownik 2 może mieć na slashdot.org ograniczony dostęp do 4KB w dół i 1KB w górę.

Na razie konfiguruję parę iptables / tc, która działa świetnie, ale na bardzo małą skalę, używając 2 lub 3 hostów wirtualnych jednocześnie (niestety nie mogę przeprowadzić testu rozmiaru rzeczywistego).

Oto moja obecna struktura (pokażę tylko tę na wyjściu z sieci LAN, ta dla przesłania jest po prostu „kopią” tej)

Qdisc HTB (uchwyt 2 :) dołączony do interfejsu, domyślną klasą ruchu jest klasa FFFF.

Klasa root 2: 1 bezpośrednio pod qdisc HTB posiadająca za szybkość i pułap pojemność DOWNLINK.

Domyślna klasa 2: FFFF jako dziecko 2: 1, ze stawką 1kbsp i pułapem pojemności DOWNLINK.

Następnie pojawiają się inne klasy dynamicznie dodawane, gdy istnieje nowe ograniczenie dla użytkownika z określonej domeny, dodawana jest nowa klasa tc, aby kontrolować prędkość pobierania z jego domeny.

Na razie oto co zrobiłem:

Utwórz nową klasę tc z unikalnym identyfikatorem (wziętym z bazy danych, nie o to tutaj), jako rodzic klasy 2: 1, wartość szybkości wynosi 1bps, wartość pułapu jest ustawiona na ograniczoną prędkość pobierania.

Oto polecenia 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 borrow bandwith from the others
$tc class replace dev $LAN_IFACE parent 0x2: classid 0x2:0x1 htb rate $DOWNLINK ceil $DOWNLINKkbps

# add the default class of class id 2:a under the main class of classid 2:1
$tc class replace dev $LAN_IFACE parent 0x2:0x1 classid 0x2:0xFFFF htb rate 1kbps ceil $DOWNLINKkbps prio 0

# add to the leaf class 2:10 for default traffic a sfq qdisc
$tc qdisc add dev $LAN_IFACE parent 0x2:0xFFFF handle 0xFFFF: sfq perturb 10

## The dynamic part called each time a new restriction for a couple domain/user is added
$tc class replace dev $LAN_IFACE parent 0x2:0x1 classid 0x2:0x$idHex htb rate 1bps ceil $speedDownkbps prio 1

# Add the sfq at the leaf class 2:1$id
$tc qdisc add dev $LAN_IFACE parent 0x2:0x$idHex handle 0x$idHex: sfq perturb 10

# $id is the mark added by iptables for this couple domain/user
$tc filter replace dev $LAN_IFACE parent 0x2:0 protocol ip prio 3 handle 0x$id fw flowid 0x2:0x$idHex
-------------- END SCRIPT --------------

Cały normalny ruch (bez ograniczenia prędkości) powinien przejść do klasy domyślnej, a ta ograniczona powinna zostać wysłana do odpowiedniej klasy tc.

Wątpię poważnie w kwestię użycia minimalnej prędkości 1 bps dla klasy domyślnej i klasy ograniczonej. Nie mogę kontrolować liczby klas ograniczonych, które zostaną utworzone, i nie chcę, aby łączna szybkość klas ograniczonych była większa niż klasa główna.

Kolejny punkt, dodałem domyślną wartość prio 0, a klasę ograniczoną prio 1, więc w przypadku gdyby klasa domyślna pożyczyła (prawie zawsze zgodnie z jej bardzo wolnym tempem), klasa ta będzie obsługiwana przed inną domeną ograniczoną. Ale czy te domeny nie umrą z głodu, jeśli utrzymam pułap domyślnej klasy jako klasy głównej?

W jaki sposób mogę pozwolić użytkownikom zachować przyzwoitą interaktywność i przepustowość dla nieograniczonego użytkowania, ograniczając jednocześnie szybkość kilku domen / użytkowników?

Zastanawiam się także, czy klasa domyślna jest tu przydatna, ponieważ jeśli nie podam; t domyślnej klasy dla qdisc htb, pakiety nie pasujące do filtrów zostaną usunięte z kolejności sprzętowej. (ale tutaj znowu z głodowaniem ograniczonej klasy?)

Jestem naprawdę nowy w tc i sieci QoS, więc wszelkie porady, krytycy (konstruktywni;)) będą mile widziane.

Vincent.

Odpowiedzi:


2

Ponieważ nie uwzględniłeś klasyfikatorów, ciężko jest odliczyć, jaki ruch masz dokładnie na myśli w każdej klasie. Na przykład wychodzący ruch http lub ssh jest bardzo ważny dla interaktywności, przychodzące http nie tak bardzo.

Zagwarantowałbym określoną przepustowość dla każdej usługi , mówiąc: Mam x kb / s dla przychodzącego ruchu httpd i jest on równo dzielony między użytkowników. Jeśli masz 10 lub 100 użytkowników, to jest sprawiedliwe. ”Jeśli masz użytkowników o wysokim priorytecie lub użytkowników o niskim priorytecie w każdej z tych usług, musisz mieć dla nich dodatkowe klasy i klasyfikatory.

(Mam również nadzieję, że wiesz, że możesz kształtować ruch wychodzący tylko z interfejsu, NIE przychodzącego. Oznacza to, że jeśli chcesz ograniczyć łącze wysyłające, musisz albo pracować z interfejsem wychodzącym do Internetu, albo korzystać z pośredniego urządzenia kolejkującego . Przewodnik lartc.org jest bardzo dobrym źródłem.)

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.