[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: język polski (było: HTB ksztaltowanie wewnatrz klasy)



Przepraszam jesli ktos zle zrozumial moj pierwotny post. Zamienmy wiec moze
slowko "routowalny" na numer z klasy publicznej ewentualniena "trasowany".
Lingwistom serdecznie dziekuje za poprawki. Zakladam, ze sa jakies grupy
dyskusyjne zajmujace sie czystoscia polskiego jezyka.  Wrazie czego polecam
google.

Na tej grupie bede jednak bardzo zobowiazany za wszelkie merytoryczne
wskazowki jak moglbym sie z tym problemem uporac.

Ponownie dzieki za wszelkie wskazowki jak sie do tego problemu zabrac! :)

----- Original Message ----- From: "Zdzisław Mikuła" <sub@astro.net.pl>
To: <debian-user-polish@lists.debian.org>
Sent: Monday, June 05, 2006 3:04 PM
Subject: HTB ksztaltowanie wewnatrz klasy


Witam,
Obecnie mam taka sytuacje, ze kazdy user ma na sztywno przydzielona
predkosc
taka za jaka placi.
Nie wnikam co on z tym robi, nie priorytetyzuje mu w zaden sposob ruchu
wewnatrz jego klasy.

Ostatnio jednak urodzil sie taki pomysl zeby kazdemu userowi przydzielic
niejako dwie predkosci.
Idea jest taka, zeby dla ruchu ciezkiego (p2p, ftp itd) zostawic userom
predkosc taka jaka maja w umowach.
Natomiast ruch np na portach 80/443 (moze tez pop/smtp ew dod
interaktywne)
przyspieszyc np dwa razy w stosunku do umowy.

Poczatkowo myslalem, zeby pomajstrowac nieco przy burstach/peekach ale
pasma
w sumie mam wiecej niz mi trzeba (zazwyczaj :) wiec mozna by zaryzykowac
ustawienie na sztywno takiej dodatkowej predkosci dla poszczegolnych
portow.

I tu powstaje pytanie jak to zrobic? W tej chwili korzystam z prostych
kolejek HTB ktore wrzucaja obecnie po IPekach ruch do poszczegolnych klas
ityle.

Tylko, ze przy takim koncepcie jak wyzej potrzebuje chyba juz czegos w
rodzaju hierarchicznych filtrow? Pierwszy powinien sklasyfikowac pakiet po
IP i wrzucic do odpowiedniej klasy. Nastepnie ten sam pakiet powinien byc
ponownie przefiltrowany pod katem portu i wrzucony znow do odpowiedniej
podklasy? Tylko jak to wlasciwie leci? Co wywoluje co? Czy klasa "szuka"
swojego filtra czy tez to HTB najpierw leci po filtrach w dol i wrzuca
pakiety do poszczegolnych klas?

Jak powinny byc zdefiniowane takie hierarchiczne filtry?

# tc filter add dev eth1 parent 10:0 protocol ip prio 1 u32 \
 match ip dst 1.2.3.4/32 flowid 10:4
# tc filter add dev eth1 parent 10:0 protocol ip prio 1 u32 \
 match ip src 1.2.3.5/32 flowid 10:5
itd ....
i dalej dla kazdego usera np ip 1.2.3.4
# tc filter add dev eth1 protocol ip parent 10:4 prio 1 u32 match \
 ip dport 80 0xffff flowid 10:44
# tc filter add dev eth1 protocol ip parent 10:4 prio 1 u32 match \
 ip sport 443 0xffff flowid 10:44
# tc filter add dev eth1 protocol ip parent 10:4 prio 2 flowid 10:444

Gdzie:
10:4 rate 512
10:44 rate 256 ceil 512
10:444 rate 256 ceil 256

Co sie dzieje z pakietem ktory trafil w dany filter (np po IP). Jak
napisac
skrypt zeby na takim trafieniu podroz pakietu po drzewie trwala dalej w
dol?

A moze prosciej by bylo markowac po prostu pakiety na iptables? Tylko ze
to
znacznie wiecej pisaniny chyba wyjdzie... No i co z wydajnoscia?

Bede wdzieczny za wskazowki. Pewnie sporo z was ma porobione
priorytetyzowanie poszczegolnych uslug wewnatrz indywidualnych klas per
user. Zakladam, ze to blizniacze rozwiazania wiec chetnie zerknolbym tez
na
taki gotowy skrypt i go sobie przerobil pod swoje potrzeby :)
Z gory dzieki,

Sub


P.S.
Do obu rozwiazan oczywiscie niezbedne bedzie dropowanie ruchu p2p z listy
portow szybszej klasy (np
przez ipp2p/L7).



Reply to: