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

IFB i pppoe - podział pasma

Post autor: aksnet » 2013-05-20, 04:31

Witam

Kilka lat temu pytałem już o konfigurację downloadu przy pomocy ifb,
ale dyskusja utknęła w martwym punkcie. Udało mi się zrobić upload na ifb
(co za chwilkę opiszę).

Posiadam autoryzację pppoe i do downloadu obecnie używam imq.
Jeśli ktoś posiada jakieś informacje jak zrobić download na ifb to będę wdzięczny.

Pokażę tu przykład uploadu na ifb (upload jest podzielony na dwie części - upload do sewera/lan i upload do internetu)
Ponieważ używam pppoe zacznę od skryptów ip-up i ip-down

/etc/ppp/ip-up

Kod: Zaznacz cały

#!/bin/bash
#
# When the ppp link comes up, this script is called with the following
# parameters
#       $1      the interface name used by pppd (e.g. ppp3)
#       $2      the tty device name
#       $3      the tty device speed
#       $4      the local IP address for the interface
#       $5      the remote IP address
#       $6      the parameter specified by the 'ipparam' option to pppd
#

# wymagane pelne sciezki do tc
/sbin/tc qdisc add dev $1 ingress
/sbin/tc qdisc filter add dev $1 parent ffff: protocol ip prio 10 u32 match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb0

/etc/ppp/ip-down

Kod: Zaznacz cały

#!/bin/bash
#
# When the ppp link comes up, this script is called with the following
# parameters
#       $1      the interface name used by pppd (e.g. ppp3)
#       $2      the tty device name
#       $3      the tty device speed
#       $4      the local IP address for the interface
#       $5      the remote IP address
#       $6      the parameter specified by the 'ipparam' option to pppd
#

# wymagane pelne sciezki do tc
/sbin/tc qdisc del dev $1 ingress


przykład podziału pasma (dla 3 pierwszych adresów ip w lan):

Kod: Zaznacz cały

# ladujemy moduly IFB 
modprobe ifb numifbs=2

ip link set ifb0 up
ip link set ifb1 up



# -----------------UPLOAD --------------------
# kasujemy poprzednie kolejkowanie 
tc qdisc del root dev ifb0 2> /dev/null 
# tworzymy nowa kolejke glowna 
tc qdisc add dev ifb0 root handle 1:0 hfsc default 2
# calkowity Upload (SUMA)
tc class add dev ifb0 parent 1:0 classid 1:1 hfsc ls m2 2928kbit ul m2 2928kbit 
# ruch nigdzie nie klasyfikowany - wazne !!!
tc class add dev ifb0 parent 1:1 classid 1:2 hfsc ls m2 100kbit ul m2 100kbit 
# upload do serwera lan 
tc class add dev ifb0 parent 1:1 classid 1:3 hfsc ls m2 1228kbit ul m2 1228kbit 
# upload do internetu 
tc class add dev ifb0 parent 1:1 classid 1:4 hfsc ls m2 1600kbit ul m2 1600kbit 

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

# pasmo dla poszczegolnych uzytkownikow 

#do serwera i LAN: 
tc class add dev ifb0 parent 1:3 classid 1:1001 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
tc filter add dev ifb0 protocol ip preference 1 parent 1:0 u32 ht 2:0x1 match ip dst 10.0.0.0/20 match ip src 10.0.1.1 flowid 1:1001
tc qdisc add dev ifb0 parent 1:1001 handle 1001:0 sfq perturb 10
#upload internet
tc class add dev ifb0 parent 1:4 classid 1:2001 hfsc ls m2 50kbit ul m1 600kbit d 7200s m2 300kbit
tc filter add dev ifb0 protocol ip preference 2 parent 1:0 u32 ht 2:0x1 match ip src 10.0.1.1 flowid 1:2001
tc qdisc add dev ifb0 parent 1:2001 handle 2001:0 sfq perturb 10


#do serwera i LAN:
tc class add dev ifb0 parent 1:3 classid 1:1002 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
tc filter add dev ifb0 protocol ip preference 1 parent 1:0 u32 ht 2:0x2 match ip dst 10.0.0.0/20 match ip src 10.0.1.2 flowid 1:1002
tc qdisc add dev ifb0 parent 1:1002 handle 1002:0 sfq perturb 10
#upload internet
tc class add dev ifb0 parent 1:4 classid 1:2002 hfsc ls m2 50kbit ul m1 600kbit d 7200s m2 300kbit
tc filter add dev ifb0 protocol ip preference 2 parent 1:0 u32 ht 2:0x2 match ip src 10.0.1.2 flowid 1:2002
tc qdisc add dev ifb0 parent 1:2002 handle 2002:0 sfq perturb 10


#do serwera i LAN:
tc class add dev ifb0 parent 1:3 classid 1:1003 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
tc filter add dev ifb0 protocol ip preference 1 parent 1:0 u32 ht 2:0x3 match ip dst 10.0.0.0/20 match ip src 10.0.1.3 flowid 1:1003
tc qdisc add dev ifb0 parent 1:1003 handle 1003:0 sfq perturb 10
#upload internet
tc class add dev ifb0 parent 1:4 classid 1:2003 hfsc ls m2 50kbit ul m1 500kbit d 7200s m2 250kbit
tc filter add dev ifb0 protocol ip preference 2 parent 1:0 u32 ht 2:0x3 match ip src 10.0.1.3 flowid 1:2003
tc qdisc add dev ifb0 parent 1:2003 handle 2003:0 sfq perturb 10



Jak widać powyżej w pierwszej kolejności (preference 1) wyłapuję ruch kierowany do LAN + serwer (dst 10.0.0.0/20)
od klienta (src 10.0.1.1) i kieruję do odpowiedniej kolejki 1:1001.

Pozostałe pakiety (preference 2) które nie są przeznaczone do LAN lub serwera są kierowanie do kolejki 1:2001
przeznaczonej na upload do internetu dla tego klienta (src 10.0.1.1).

Przy okazji używam tu filtrów hashujących.

Tak to wygląda w skrócie. Wszystko ładnie działa.

Czy jest możliwe zrobienie na ifb downloadu mając autoryzację pppoe?
Chciałbym całkowicie zrezygnować z imq i pozostać tylko przy ifb.
Szukam jakiejś podpowiedzi i kierunku do dalszej walki z IFB :)


Pozdrowienia

aksnet
Ostatnio zmieniony 2013-05-23, 05:19 przez aksnet, łącznie zmieniany 2 razy.

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-20, 08:02

A w jakim celu robisz upload na ifb /komplikujesz IMO/, do kształtowania upload czyli ruchu wychodzącego nie potrzeba do tego ifb spoko wystarczy ppp.
Na ifb zrób sobie download i przekieruj sobie ingress z ppp. Reszta podobnie jak zrobiłeś na up tylko kierunki i przepustowości inne.
Zreszta z twojego wpisu wychodzi ,że masz internet, lan, server ,upload , download na jednym interfejsie coś na moje gusta za wiele tego jak na jednego wielbłąda.

Jeszcze uwaga o hfsc
tc class add dev ifb0 parent 1:3 classid 1:1001 hfsc ls m2 102kbit ul m1 1024kbit d 3600s m2 512kbit
dajesz ls gościowi 102kbit to po kiego rozszerzasz mu ograniczenie ul do 1024 na sic! godzinę by po czasie obniżyć do 512.
Mało tego każdemu gościowi chcesz te 1024 rozszerzyć na ... godzinę to dla trzech jest już 3072 a to co możesz zaoferowałeś dla wszystkich ograniczyłeś w parent 1:3 do 1228kbit ????
Z dwóch poprzednich zdań wynika też wniosek ,że jak wyżej w kolejce założyłeś ograniczenie na ul to w liściach /node/ jest to zupełnie zbędne bo o podział dba ls /link share/. To nie jest htb gdzie byłeś obowiązany stosować paramet rate łącznie z ceil.

Dlatego możesz napisać ,że "wszystko ładnie działa" oczywiście bo parametr ul jest opcjonalny w przeciwieństwie do ceil z htb i nie ma tu wiele do powiedzenia, ale na pewno nie działa z ta logika którą zapodałeś .
Powodzenia

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 » 2013-05-20, 08:24

(upload od 102kbit do 1024kbit przez pierwszą godzinę, po godzinie od 102kbit do 512kbit)
To jest upload do serwera i jest wykorzystany bardzo rzadko (wyłącznie na lokalne www z którego prawie nie ściąga się plików,
może czasem jakiś plik raz na tydzień). Klienci mają zablokowanie przesyłanie do siebie po lan.
Takie prędkości i czasy są u mnie wystarczające do załadowania raz na parę dni strony www :)
Jeśli ktoś ma inne wymagania w sieci może sobie zmienić te prędkości.


Pewnie, że mogę robić podział osobno na każdym ppp. Tylko jak ograniczyć pasmo tak aby suma całego przydzielonego pasma na
wielu interfejsach ppp nie przekroczyła przepustowości łącza? Jaki masz pomysł? Do tego chyba potrzeba jednej kolejki głównej i jednego interfejsu.
Może się jednak mylę ...

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-20, 09:15

"(upload od 102kbit do 1024kbit przez pierwszą godzinę, po godzinie od 102kbit do 512kbit)"

OK to mnie się poplatało wyjaśniając ul myslałem o ls :-) dodam tylko, że to nie jest od 102kbit. Link share operuje na ratio łącza, a nie na bezwzglednych wartościach wyrażonych w kbit te są jedynie wymagane przez filtr tc.Możesz śmiało podawać np po 1kbit czy 1000kbit i tak liczy sie ratio ograniczane w ramach ul lub przepustowości łącza :-)

"Pewnie, że mogę robić podział osobno na każdym ppp."

NIe czaiłem tej topologii i nadal mam problem .Rozumiem, że jak nie dajesz ludziom hasać po lanie i każdy ma dostęp po ppp to OK zostaje IFB jako ingress od strony userów co wykonałeś tylko nadal nie więm z czym problem z downloadem bo ifb bedzie działął podobnie jak imq jako ingress od strony internetu na łączu internetowym.

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 » 2013-05-20, 10:25

Możesz podać jakiś najprostszy przykładzik downloadu na ifb?
(załóżmy że jest zalogowanych dwóch użytkowników ppp0 i ppp1).

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-20, 12:28

Nadal nie wiem co ty chcesz robic i w jakiej konfiguracji /topologia sieci/
i co ma do tego ppp0,ppp1...ppp-nte skoro przechodzi to przez serwer tak jak rozumiem najprościej czyli jednej karcie sieciowej od strony lanu eg. eth0 , który to serwer jak rozumiem łączy się z netem inna kartą sieciową eth1 .
Tak to rozumiem bo nie podałeś żadnych wskazówek.
Agregacja w stylu ppp+ podobnie jak w IMQ od strony lanu /użytkowników/ za pomoca IFB i filtrów ip jest chyba niemożliwa .
Chyba bo być może są jakieś rązwiązania.
Zostało by kształtowanie na każdym ppp co odpada pewnie.
Ale przecież ruch z internetu możesz kształtować na fejsie wychodzących eth1 w tym przykłądzie zakłądąjąc tam IFB i przekierowując na adresy IP zalogowanych użytkowników.

a to juz wiesz jak robić:

/sbin/tc qdisc add dev eth1 ingress
/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

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 » 2013-05-20, 12:48

Jest tylko jeden problem. Robisz to wszystko przed natem.
wszystkie adresy ip które masz dostępne to są adresy zewnętrzne
(może to być nawet jeden zewnętrzny adres ip).
Nie można tu zastosować filtrów po adresach ip jakie są od strony lan.
Gdyby dało się tak zrobić nikt nie używałby IMQ.


Na karcie od strony wan (jak to napisałeś eth1) da się zrobić tylko upload.
Najpierw markujemy pakiety przychodzące od strony lan, a po nacie
rozpoznajemy je juz tylko po markach.

Robiłem tak kiedyś upload (wan to eth0) :

Kod: Zaznacz cały

# -----------------UPLOAD --------------------
iptables -t mangle -N UPLOAD1 2> /dev/null
iptables -t mangle -F UPLOAD1

iptables -t mangle -D PREROUTING -s 10.0.1.0/24  -g UPLOAD1 2> /dev/null
iptables -t mangle -A PREROUTING -s 10.0.1.0/24  -g UPLOAD1

# kasujemy poprzednie kolejkowanie 
tc qdisc del root dev eth0 2> /dev/null 
#--- kolejka glowna - upload  ---
tc qdisc add dev eth0 root handle 1:0 hfsc default 2
#--- calkowity upload ------
tc class add dev eth0 parent 1:0 classid 1:1 hfsc ls m2 1700kbit ul m2 1700kbit
#--- kolejka ruchu nieklasyfikowanego - bardzo wazne !!!
tc class add dev eth0 parent 1:1 classid 1:2 hfsc ls m2 100kbit ul m2 100kbit
#--- upload ------
tc class add dev eth0 parent 1:1 classid 1:3 hfsc ls m2 1600kbit ul m2 1600kbit

# pasmo dla poszczegolnych uzytkownikow 

#upload
iptables -t mangle -A UPLOAD1 -s 10.0.1.1 -j MARK --set-mark 1001
tc class add dev eth0 parent 1:3 classid 1:1001 hfsc ls m2 50kbit ul m1 500kbit d 7200s m2 250kbit
tc filter add dev eth0 protocol ip parent 1:0 handle 1001 fw flowid 1:1001
tc qdisc add dev eth0 parent 1:1001 handle 1001:0 sfq perturb 10


#upload
iptables -t mangle -A UPLOAD1 -s 10.0.1.2 -j MARK --set-mark 1002
tc class add dev eth0 parent 1:3 classid 1:1002 hfsc ls m2 50kbit ul m1 500kbit d 7200s m2 250kbit
tc filter add dev eth0 protocol ip parent 1:0 handle 1002 fw flowid 1:1002
tc qdisc add dev eth0 parent 1:1002 handle 1002:0 sfq perturb 10


#upload
iptables -t mangle -A UPLOAD1 -s 10.0.1.3 -j MARK --set-mark 1003
tc class add dev eth0 parent 1:3 classid 1:1003 hfsc ls m2 50kbit ul m1 500kbit d 7200s m2 250kbit
tc filter add dev eth0 protocol ip parent 1:0 handle 1003 fw flowid 1:1003
tc qdisc add dev eth0 parent 1:1003 handle 1003:0 sfq perturb 10

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-20, 13:34

"Gdyby dało się tak zrobić nikt nie używałby IMQ."

Kiedyś był taki patch na jądro 2.6 pod nazwą esfq który nakładałeś na kolejke miast sfq by widzieć ip wewn zza natu.
Dzisiaj w nowych jądrach choc nie tak znów nowych są nowe opcje dla sfq , które dają funkcjonalność esfq.

Dawno tego nie robiłem ale dodaje sie przykładową linijkę :

Kod: Zaznacz cały

tc filter add dev ifb0 parent 12: handle 12 protocol all flow hash keys nfct-src,dst,nfct-proto-src,proto-dst  divisor 1024
i może nat nie będzie problemem, a pakiety wędrować do odpowiednich ip wewn
oczywiście atrybutami keys można dopasować do swoich potrzeb w zależności od okoliczności

http://lwn.net/Articles/236200/
i tu ładny opis

http://www.wlug.org.nz/TrafficControl

PS.

Właściwie do ruchu przychodzącego powinno byc pewnie "nfct-dst" trzeba popróbować opcji po to są.
Ostatnio zmieniony 2013-05-20, 13:50 przez PITbull, łącznie zmieniany 1 raz.

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-20, 13:37

Marki na IFB nie działaja bo jest przed iptables.

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 » 2013-05-20, 13:47

Pisałem o markach na eth

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-20, 14:26

"Na karcie od strony wan (jak to napisałeś eth1) da się zrobić tylko upload."

Po to popełniono IFB ,żeby sie dało zrobić download i po to dodano do "flow control" opcje typu nfct-src lub nfct-dst by móc kształtowac na kolejkach ruch z i do .

POwodzenia.

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 » 2013-05-21, 07:51

Dzięki za informacje. Jeśli uda mi się pójść do przodu to wstawię rozwiązanie na forum.

aksnet

Awatar użytkownika
webster
Użytkownik
Posty: 1265
Rejestracja: 2009-10-06, 11:58
Lokalizacja: Gdańsk
Kontakt:

Re: IFB - podział pasma

Post autor: webster » 2013-05-21, 08:07

Z ciekawym, ładnym how to poproszę :) Przyda się do FAQ
††† Chaos Of The Mirror - Valheru †††
††† I ♥ SlackWare RuLeZ †††

Slackware Poland FaceBook

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-21, 08:45

Taki szybki przykład nie wiem czy będzie działał tylko przykład.
/sbin/tc qdisc add dev eth1 ingress
/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

#--- kolejka glowna - dn---
tc qdisc add dev ifb0 root handle 1:0 hfsc default 2
#--- calkowity dn ------
tc class add dev ifb0 parent 1:0 classid 1:1 hfsc ls m2 1700kbit ul m2 1700kbit
#--- kolejka ruchu nieklasyfikowanego - bardzo wazne !!!
tc class add dev ifb0 parent 1:1 classid 1:2 hfsc ls m2 100kbit
#--- dn ------
tc class add dev ifb0 parent 1:1 classid 1:3 hfsc ls m2 1600kbit
...
tutaj
pominięte inne dodatkowe reguły nieistotne na razie dla przykładu co by nie komplikować
....
//zakładamy filtr bezklasowy SFQ na klasę 1:3

tc qdisc add dev ifb0 parent 1:3 handle 3: sfq perturb 10

ZAkładamy filtr na sfq co by dzielił sprawiedliwie po równo w ramach klasy 1:3 tylko po adresie docelowym wewn lan. "nfct-dst".

tc filter add dev ifb0 parent 3: handle 3 protocol all flow hash keys nfct-dst divisor 1024

i wszystko.Zero regółek na każde IP osobno, choc i tak też można.
Może o czymś zapomniałem , ale chodzi o sposób a nie gotowiec.
Hope it helps.

PITbull
Użytkownik
Posty: 158
Rejestracja: 2004-10-19, 18:50

Re: IFB - podział pasma

Post autor: PITbull » 2013-05-21, 09:57

webster

Przydałby się faq o samym hfsc bo jak widzę , że 98% zastosowań powiela bezmyślnie logike htb to zadaję sobie pytanie po co ci goście używają hfsc /moda/.
To tak jak by gość stale jeżdżący na ośle przesiadłszy się na araba dostrzegał w nim dalej osła.
W jednej wiki wyczytałem porażające porównanie , żę główną różnica między htb i hfsc jest sic! różnica w traktowaniu ruchu defaultowego.
To tak jak by ktoś napisał od nowa netfilter i zmienił jedynie domyślna polityke z accept na deny .
Porażająca róznica. Prawda :-)

ODPOWIEDZ