IFB i pppoe - podział pasma

Serwery i sieci oparte na Slackware, wszelkiego rodzaju usługi, troubleshooting.

Moderatorzy: Moderatorzy, Administratorzy

Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB - podział pasma

Post autor: aksnet »

zamiast:

Kod: Zaznacz cały

/sbin/tc qdisc filter add dev eth1 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb0
powinno być raczej (kernel 3.2 wyrzuca u mnie błędy):

Kod: Zaznacz cały

/sbin/tc filter add dev eth1 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb0
Ogólnie skrypcik działa, ale najtrudniejsze do przejścia będzie ustawienie różnego downloadu dla różnych adresów IP na LAN.
np:
dla 10.0.1.1 - 512kbit
dla 10.0.1.2 - 1024kbit
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB - podział pasma

Post autor: aksnet »

Mam już działającą konfigurację downloadu (chociaż nie została przetestowana jeszcze dla większej ilości interfejsów ppp).
Podział downloadu został zrobiony na interfejsie ifb2

dla każdego interfejsu ppp tworzymy tylko kolejkę główną:
(przykład dla ppp0)

Kod: Zaznacz cały

/sbin/tc qdisc add dev ppp0 root handle 1:0 hfsc
i robimy przekierowanie downloadu do ifb2 (dla downloadu używamy parent 1:, zamiast poprzednio używanego dla uploadu parent ffff: ):
(przykład dla ppp0)

Kod: Zaznacz cały

/sbin/tc filter add dev ppp0 parent 1: protocol ip prio 10 u32 match u32 0 0 action mirred egress redirect dev ifb2
a więc ogólnie dla wszystkich interfejsów ppp:

dopisujemy do:
/etc/ppp/ip-up

Kod: Zaznacz cały

/sbin/tc qdisc add dev $1 root handle 1:0 hfsc
/sbin/tc filter add dev $1 parent 1: protocol ip prio 10 u32 match u32 0 0 action mirred egress redirect dev ifb2
dopisujemy do:
/etc/ppp/ip-down

Kod: Zaznacz cały

/sbin/tc qdisc del root dev $1
Po dodaniu wpisów do ip-up i ip-down podział downloadu wygląda u mnie identycznie jak na imq (zamieniłem tylko w skrypcie imq na ifb):

Kod: Zaznacz cały

# -----------------DOWNLOAD --------------------
# kasujemy poprzednie kolejkowanie 
tc qdisc del root dev ifb2 2> /dev/null 
# tworzymy nowa kolejke glowna 
tc qdisc add dev ifb2 root handle 1:0 hfsc default 2
# calkowity download 
tc class add dev ifb2 parent 1:0 classid 1:1 hfsc ls m2 16828kbit ul m2 16828kbit 
# ruch nigdzie nie klasyfikowany - wazne !!!
tc class add dev ifb2 parent 1:1 classid 1:2 hfsc ls m2 200kbit ul m2 200kbit 
# download z serwera + lan 
tc class add dev ifb2 parent 1:1 classid 1:3 hfsc ls m2 1228kbit ul m2 1228kbit 
# download z internetu 
tc class add dev ifb2 parent 1:1 classid 1:4 hfsc ls m2 15400kbit ul m2 15400kbit 

# reguly dla filtrow HASH 
tc filter add dev ifb2 parent 1:0 protocol ip u32 
tc filter add dev ifb2 parent 1:0 handle 2:0 protocol ip u32 divisor 256 
tc filter add dev ifb2 parent 1:0 protocol ip u32 ht 800:: match ip dst 10.0.1.0/24 hashkey mask 0x000000ff at 16 link 2: 

# pasmo dla poszczegolnych uzytkownikow 

#z serwera i LAN: 
tc class add dev ifb2 parent 1:3 classid 1:1001 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
tc filter add dev ifb2 protocol ip preference 1 parent 1:0 u32 ht 2:0x1 match ip src 10.0.0.0/20 match ip dst 10.0.1.1 flowid 1:1001
tc qdisc add dev ifb2 parent 1:1001 handle 1001:0 sfq perturb 10
#download z internetu
tc class add dev ifb2 parent 1:4 classid 1:2001 hfsc ls m2 1024kbit ul m1 5120kbit d 5400s m2 2048kbit
tc filter add dev ifb2 protocol ip preference 2 parent 1:0 u32 ht 2:0x1 match ip dst 10.0.1.1 flowid 1:2001
tc qdisc add dev ifb2 parent 1:2001 handle 2001:0 sfq perturb 10


#z serwera i LAN: 
tc class add dev ifb2 parent 1:3 classid 1:1002 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
tc filter add dev ifb2 protocol ip preference 1 parent 1:0 u32 ht 2:0x2 match ip src 10.0.0.0/20 match ip dst 10.0.1.2 flowid 1:1002
tc qdisc add dev ifb2 parent 1:1002 handle 1002:0 sfq perturb 10
#download z internetu
tc class add dev ifb2 parent 1:4 classid 1:2002 hfsc ls m2 1024kbit ul m1 5120kbit d 5400s m2 2048kbit
tc filter add dev ifb2 protocol ip preference 2 parent 1:0 u32 ht 2:0x2 match ip dst 10.0.1.2 flowid 1:2002
tc qdisc add dev ifb2 parent 1:2002 handle 2002:0 sfq perturb 10


#z serwera i LAN: 
tc class add dev ifb2 parent 1:3 classid 1:1003 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
tc filter add dev ifb2 protocol ip preference 1 parent 1:0 u32 ht 2:0x3 match ip src 10.0.0.0/20 match ip dst 10.0.1.3 flowid 1:1003
tc qdisc add dev ifb2 parent 1:1003 handle 1003:0 sfq perturb 10
#download z internetu
tc class add dev ifb2 parent 1:4 classid 1:2003 hfsc ls m2 512kbit ul m1 2560kbit d 5400s m2 1024kbit
tc filter add dev ifb2 protocol ip preference 2 parent 1:0 u32 ht 2:0x3 match ip dst 10.0.1.3 flowid 1:2003
tc qdisc add dev ifb2 parent 1:2003 handle 2003:0 sfq perturb 10
Aby mieć pewność że wszystko działa poprawnie zamierzam zrobić testy dla większej ilości interfejsów ppp (kilkadziesiąt).
W moim przypadku będzie to koniec używania IMQ :)
Ostatnio zmieniony 2013-05-25, 06:47 przez aksnet, łącznie zmieniany 2 razy.
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

Po 2 dobach pracy (60 interfejsów pppoe) nie zauważyłem jakichkolwiek problemów.
Odnoszę wrażenie, że szybkie gry np. Urban Terror (strzelanka sieciowa) chodzą na IFB płynniej niż przy podziale pasma z użyciem IMQ.
IMQ poszło ostatecznie do kosza na rzecz IFB :)

Pozdrawiam wszystkich

aksnet
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

Czy ktoś już wdrożył u siebie ifb w podobny sposób jak opisany?
Przyznaję że jestem bardzo zadowolony z jego działania i z tego, że uwolniłem się od imq z wraz kompilacją kernela :)
Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)

Re: IFB i pppoe - podział pasma

Post autor: bojleros »

Z mojej praktyki mogę powiedzieć tyle:

1. HFSC jest algorytmem bardziej wymagającym obliczeniowo niż HTB. Jeżeli ktoś chce zrobić bardziej skomplikowaną konfigurację na jakimś *wrt albo starszym PC to może się spodziewać zarżnięcia sprzętu. Pozwala za to uzyskać o wiele lepsze efekty ;)

2. Kiedyś zauważyłem że gdy do klasy podpinam kolejkę *sfq to co pewien czas (o dziwo niezwiązany z parametrem perturb) jeden z pakietów potoku danych przychodził ze znacznie większym opóźnieniem (normalnie ~40ms, pik co ~10 pakietów ~120ms). Na kolejkach fifo tego nie było. Od tego czasu *sfq używam rzadko. Może ktoś się spotkał z czymś podobnym ?

3. Kiedyś IFB zawieszało mi system (kernel-piknik). Od tego czasu nie używałem.

Możesz mi powiedzieć czy diagram zawarty pod linkiem http://l7-filter.sourceforge.net/PacketFlow.png jest nadal aktualny ??
Z tego by wynikało że ifb nadal nie nadaje się do dzielenia downloadu per-user .....
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

"Z tego by wynikało że ifb nadal nie nadaje się do dzielenia downloadu per-user ....."
Nadaje się i właśnie tak go używam (problemów brak na Slackware 14.0).

Przeczytaj dokładniej moje posty w bieżącym wątku:
z 22 maja 2013, o 08:25 (download per user)
i z 20 maja 2013, o 04:31 (upload per user)
PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB i pppoe - podział pasma

Post autor: PITbull »

bajleros

AD1 . JA nie wiem czy jest bardziej wymagający. NAtomiast ludzie używają całej mocy HFSC by skopiować to co robi HTB.Wtedy owszem.
Zauważ ,że zarządca /sheduler/ ls- link share nie dzieli w czasie rzeczywistym, jak chociażby wiadro żetonów w HTB. Dla niego parametrem jest podział wg ratio łącza nawet 1000GB, a więc teoretycznie podzieli na każdym sprzęcie bo czas go nie ogranicza.To w zupełności wystarcza by parodiować HTB z małym narzutem mocy obliczeniowej.
No ale jakoś sie ludziska uparli ,żeby podwajać obliczenia i stosuja gdzie tylko można i ls i ul i rt byle jak najwięcej - no to wtedy rzeczywiście staje się to bardzo wymagające.

AD2. SFQ daje latency no i potrafi "przerzucić" sobie pakiet zmieniając sekwencję kolejność taka jego natura co przy UDP może być niezbyt, potrenuj z nowym CODEL ma podobno latency na poziomie fifo przy sprawiedliwym podziale jak w SFQ. Stworzony by zapobiegać bufferbloat.

"Z tego by wynikało że ifb nadal nie nadaje się do dzielenia downloadu per-user ....."

A dlaczegóż to?
KOlega aksnet lubi koronkową robotę i zrobił to na swój sposób.
JA zrobiłbym to poprzez tc i parametr zewnętrzny flow control per user, a łącze podzieliłbym HFSC per usługa.
Dwa w jednym , wzglednie mały narzut obliczeniowy /ilość reguł/ i wykorzystanie tego co daje HFSC czyli nie tylko podział jak HTB tylko multipleksyzacja ruchu w ramach łącza
To że IFB działa przed wszystkimi regułami netfilter wcale go nie przekreśla IMHO.
Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)

Re: IFB i pppoe - podział pasma

Post autor: bojleros »

aksnet Czy używasz na tej maszynie maskaradowania ?

Kurcze , przekopałem Wasze posty jednak dalej nie jestem w stanie złapać w jaki sposób w IFB dla kierunku download pojawia się informacja o adresie IP maszyny zza maskarady. W listingach aksneta nie pojawiają się opcje flow hash keys wskazywane przez PITbulla ... chybaże przyjmuje błędne założenia a maskarady nie ma ?? Możecie mi to naświetlić ??


AD1. Kiedys prowadziłem o tym rozmowę z gościem co pisał o HFSC jakiś konkretniejszy papier. Według informacji jakie mam od niego to sam mechanizm rt wymaga obliczania czasów opóźnienia dla każdego z pakietów jakie wprowadza HFSC i na tym miała niby polegać róznica względem HTB.

AD2. Zobaczę. Dawno już nie kompilowałem kernela i nie jestem na bieżąco z nowościami.

AD3. Rozumiem że nie macie negatywnych doświadczeń ze stabilnością samego IFB ?


Generalnie od dłuższego czasu nikt już nie uzupełnia LARTC. Znacie jakieś inne źródło (aktualnej) wiedzy na ten temat ?

Z góry dzięki!
PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB i pppoe - podział pasma

Post autor: PITbull »

W listingach aksneta nie pojawiają się opcje flow hash keys wskazywane przez PITbulla ...
Wydaje mi sie /bo sam autor nie zechciał /nie musiał/ tego wyjaśnić/ ,że aksnet robił to od strony lanu per każde ppp przekierowując użytkowników do wspólnego IFB coś w podobie jak regułą iptables przekierowujesz wiele interfejsów /ppp+/ do IMQ /nigdy tego tak nie robiłem - mam na myśli IFB/ więc nie było pewnie potrzeby kontrolować przepływ ze względu na destination pakietu za maskaradą :-)
Według informacji jakie mam od niego to sam mechanizm rt wymaga obliczania czasów opóźnienia dla każdego z pakietów jakie wprowadza HFSC
Tylko ,że rt nie jest niezbędne do prostego podziału łącza a'la HTB. Wystarczy ls samodzielnie jak również można rt samodzielnie choć tak naprawdę nie zostało do tego zaprojektowane.
Ogólnie rzecz biorąc cała róznica między HFSC i HTB w jednym zdaniu jest taka ,że rozdzielono zadania na dwóch zarządców:
ls ma za zadanie dzielić łącze wg zadanego ratio (wartości bezwzględne są tu nieistotne w odróżnieniu od rate w HTB) w czasie wirtualnym niejako zależnym jedynie od przepustowości, a rt odpowiada za opóżnienia i gwarantowanie pasma w czasie rzeczywistym /i w tym sensie jest do rate z HTB troszkę podobne/.
Czyli dzielisz ls i dajesz "wstawki" rt tam gdzie jest to wymagane, a nie powołujesz dwóch zarządców do zrobienie identycznej rzeczy bo wtedy żaden z nich nie spełni zaadań do których został zaprojektowany.

Problem w tym ,że jest słaba dokumentacja i wiele zastosowań to ls i rt w jakiś dziwnych koligacjach kopiujących HTB /np. stosowane razem dla identycznego celu - czyli niejako połaczenie dwóch zarządców razem, a więc zaprzeczenie idei do jakiego wprowadzono podział , a co za tym idzie cofnięcie się do filozofii HTB kosztem zbędnego komplikowania / a także nadużywanie ul w liściach aby tylko powielić schemat znany z HTB niwecząc nowe możliwości /nawiasem nie zawsze potrzebne w gro zastosowań/ wynikające z rozdziału zadań .

Tu jest najlepszy jak do tej pory help IMHO na kilku stronach dyskusji do zrozumienia hfsc

http://www.spinics.net/lists/netdev/msg183182.html
http://www.spinics.net/lists/netdev/msg183209.html
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

bojleros

Do rutowania używam SNAT, ale nie ma to większego znaczenia bo (tak jak już odpowiedział PITbull)
download dzielę od strony lan (a więc PRZED NAT).

Po prostu dość uparcie eksperymentowałem przez kilkanaście godzin (może więcej?) i udało się wynaleźć koło na nowo :)
Znalazłem na jakimś forum (chyba Debiana) informację o tym jak zrobić download na interfejsie ifb po przekierowaniu do niego ruchu
wychodzącego z eth0 (od strony lan). Uogólniłem przykład na wszystkie interfejsy ppp używając do tego skryptów ip-up oraz ip-down i poszło.

np:
przekierowanie ruchu wszystkich ppp do imq0 wygląda tak:
iptables -t mangle -A PREROUTING -i ppp+ -j IMQ --todev 0
a przekierowanie ruchu wszystkich ppp do ifb0 robię w skrypcie /etc/ppp/ip-up
(szczegóły w poście z 22 maja 2013, o 08:25)
Różnica polega tylko na sposobie przekierowania ruchu do interfejsu ifb
(filtr jest na każdym ppp osobno zamiast jednej regułki iptables dla wszystkich ppp).

Podział downloadu na ifb jest już zrobiony identyczne jak download z użyciem imq (lub eth).
Podobno na ifb nie działa markowanie, ale markowanie akurat nie było potrzebne.

Robiąc podział pasma przed NAT mam kontrolę nie tylko nad downloadem z internetu, ale dodatkowo
także nad downloadem z serwera/lan , co dla mnie jest dość przydatne (najpewniej po NAT nie da się tego tak zrobić).

Nie udało mi się zrobić podziału downloadu (per ip) na ifb umieszczonym za NAT i nie planuję nad tym pracować.

Używam tu może zbyt prostego HFSC, ale głównym powodem przejścia z HTB do HFSC była potrzeba
ograniczenia użytkownikowi pasma po pewnym czasie (po godzinie- dwóch). Takiej możliwości chyba nie ma w HTB.
Nie zaprzeczę, że przydałaby się dobra dokumentacja do HFSC :)

PS.
Dwa tygodnie pracy serwera (w dzień średnio 60-65 interfejsów ppp przy 80 użytkownikach)
dwa łącza internetowe i 4 interfejsy IFB (dla każdego łącza upload i download na ifb)
Problemy : BRAK
Wygląda na to że IFB jest stabilne.
Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)

Re: IFB i pppoe - podział pasma

Post autor: bojleros »

Dziękuje za odzew :)

Od strony stabilności to naprawdę dobra informacja.

Moje "uparte eksperymenty" datują się na czas przełomu kerneli 2.4 i 2.6 a jak wiadomo od tego czasu już trochę minęło. Teraz pewnie będę musiał wiedzę odświeżyć bo mamy klienta w sieci co sobie kupił poważny soft do wideokonferencji i będzie chciał mieć gwarantowane pasmo.

Jeżeli jesteście zainteresowani to mogę jeszcze polecić jeden test -> uruchomienie pewnego programu p2p (informacja na priv). Paskudztwo generuje sporo małych pakietów przez co miałem kiedyś z tym poważne problemy bo ograniczenia nie dawały rady. Sprawa wyszła dość dawno temu i szczegółów nie przytoczę ale skończyło się to twardym blokowaniem za pomocą layer7 i limitami pps.

Btw. Słyszeliście o patchu który implementowałby dla HFSC parametr prio w sensie tego z HTB ?
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

Witam wszystkich
Po 4,5 miesiąca użytkowania jeszcze raz mogę potwierdzić 100% stabilność i brak problemów z ifb na slackware 14.0.
Używam 4 interfejsów ifb (ok. 90 użytkowników w sieci)
2 łącza internetowe jednocześnie:
1 łącze: download: ifb0, upload: ifb1
2 łącze: download: ifb2, upload: ifb3

Jestem bardzo zadowolony i zapomniałem już o imq i kompilacjach jądra :)

Pozdrawiam.
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

Witam

Używam z powodzeniem tak skonfigurowanego IFB już ponad 2 lata i potwierdzam stabilność.
Polecam wszystkim zamiast IMQ (już zapomniałem o kompilacji jądra :) ).

Aksnet
Ostatnio zmieniony 2015-08-18, 20:01 przez aksnet, łącznie zmieniany 1 raz.
Awatar użytkownika
bojleros
Użytkownik
Posty: 785
Rejestracja: 2005-08-29, 11:12
Lokalizacja: z widokem na familoki :)

Re: IFB i pppoe - podział pasma

Post autor: bojleros »

Cześć,

Aksnet, bardzo ładny wynik. Dobrze wiedzieć że IFB ma się dobrze. Może lekko naiwne pytanie ale czy przez te dwa lata podnosiłeś wersję kernela ? Ciekawy jestem jak się ma IFB z wersji na wersję.

Osobiście od pewnego czasu jestem bardzo zadowolony z Mikrotika z PCQ.

Pozdrawiam,
Awatar użytkownika
aksnet
Użytkownik
Posty: 70
Rejestracja: 2008-03-02, 19:09
Lokalizacja: z 10.0.1.1

Re: IFB i pppoe - podział pasma

Post autor: aksnet »

Cześć

Nie zmieniałem wersji kernela. Czekam na nowe wydanie Slackware :)
ODPOWIEDZ