W dniu 06.09.2012 13:01, Tomasz Chiliński pisze:
W dniu 06.09.2012 12:33, Łukasz Czerepuk napisał(a):
Troche w biegu odpisuje, ale wydaje mi sie, ze :
$TC filter add dev $WAN protocol ip parent 1:0 u32 match ip src 10.10.9.63 flowid 1:112
nie jest potrzebne. Masz ladne ciecie UPLOADu dla $WAN, a potem masz ciecie DOWNLOADu dla $LAN, wiec powinno zostac tylko: $TC class add dev $LAN parent 1:1 classid 1:112 htb rate 2048kbit ceil 8092kbit $BURST c$BURST $TC filter add dev $LAN protocol ip parent 1:0 u32 match ip dst 10.10.9.63 flowid 1:112
Ale jak mowie, odpisuje w biegu, wiec moge sie mylic. ;- )
2 klasy, które regulują szybkość i 2 filtry klasyfikujące na każdym z kierunków do tych klas, więc jest dobrze. Ale za to jest zupełnie nieoptymalnie, bo klasyfikowanie filtrami działa teraz tak, że dla każdego pakietu na danym kierunku przegląda wszystkie filtry i patrzy, którego warunki pasują. Przerób te filtry tak, żeby używały tabeli opartej o funkcję mieszającą (hashing table). Średnia złożoność klasyfikacji pakietów spadnie z n/2 do n/m, gdzie m będzie bardzo dużą wartością całkowitą. Dopiero wtedy można mówić o sensownej konfiguracji shapingu.
Nie wiem czemu wszyscy uparcie używają filtrów u32, skoro filtry fw z automatu są trzymane przez jądro w strukturze używającej funkcji mieszającej. Wystarczy zajrzeć do źródeł implementacji filtrów fw i widać czarno na białym.
Ja korzystałem nieco z dokumentacji w LMS, troche samemu kombinowałem i to było to, co udało mi się zrobić. Może w takim razie, skoro teraz są lepsze metody to ktoś (TM) mógłby to uaktualnić w dokumentacji? Przyznam szczerze, że mi to by ułatwiło życie niż teraz szukać i kombinować i pewnie innym userom również ;-)