Linux за българи: Форуми

или както предполагам - не?

Идеята е следната:
                            ____
internet ----> ne3|           | we0 <------------ local net 1 (192.168.1.0/24)
                            -------- ep1 <------------- local net 2 (192.168.0.0/24)

По средата кутийката е OpenBSD с пуснат NAT, бла бла...

Въпроса е следния - да кажем, че download-а ми е ограничен на 1Mb. Мога ли тоя 1Mb да го разпределя така: 1/3 към local net 2 и 2/3 към local net 1, като ако не се използва да кажем от local net 2 трафика да отива към local net 1.

Сега, подозирам, че принципно не може да стане това нещо, т.к. доколкото знам при всички системи за shape-ване се определя скорост за интерфейс, но моите познания са доста начални в тая област, така че ще замоля някой по-запознат да ме осветли.

Принципно шейп на много интерфейси става само с IMQ (в контекста на tc) ...
http://lartc.org/lartc.html#LARTC.IMQ

Ммм благодаря.

Сега ако някой каже как се прави това с PF ще е чудно.

Понеже мислих по въпроса и ще взема да споделя какво съм измислил, та някой да каже дали има резон. Значи, т.к. опашка може да се прави само за един интерфейс (поне с pf/altq), значи трябва по някакъв начин да се обединят двата интерфейса. Това ме наведе на мисълта за bridge. Та, ако пусна bridge интерфайс м/у двата интерфейса за локалните мрежи и му закача на него опашката се чудех дали няма да стане нещо подобно на това което искам.

p.s. може би трябва да се премести тая тема в bsd секцията, знам ли...

Значи, пробвах да направя тая хава с bridge-а, обаче pf се оплаква, че bridge драйвера не поддържа altq. Щукна ми, че бих могъл през някакъв loopback интерфейс да прекарам трафика за двете мрежи и на него да shape-вам, обаче нещо не мога да се светна как трябва да се реализира това.

Ще съм благодарен за малко помощ.

сложи още една машина пред тази и ето ти го единия интерфейс :-)

да, вярно :)

само дето аз се чудя къде да слагам щайгите дето ги имам в момента в нас, ти ми предлагаш още една да сложа. :)

Mozhesh da napravish i taka:
sheipni si dvata interfeisa kato im zadavash max skorost kakvato pozhelaesh,
no im slozhi razlichni prioriteti. Sheipni i vunshniia interfeis kato zadadesh razlichni prioriteti na queue-tata za trafica idvassht ot razlichnite vutreshni interfeisi.

Ъъъъ, какво ще постигне така?

можеш да си шейпнеш всички интерфейси, в това ограничение няма
за да ти е равномерен шейпъра за DL на users слагаш един главен (parent) клас който ще ти е пълната линия или максимума с който искаш да точат users в случая трябва да създадеш 2 главни класа за всеки интерфейс по отделно и е
по правило се оставя малко свободно място да може да диша линията ако имаш 1Мбит слагаш главния на 900Кбит а при теб трябва да укажеш в главните класове по колко Кбит да се дава на всеки интерфейс
след което създаваш за потребителите един подклас ( в твоя случай два за всеки интерфейс по един ) който да е закачен (bonded) към главния клас и потребителското ограничение го пускаш на 64Кбит като не го ограничаваш тотално с него а го оставяш "плаващо" т.е. потребителите да вземат един от друг когато линията е празна
по този начин точещия Гошко установява че като се включи Пенчо да точи и скоростта му пада на половина

но запомни нещо... можеш да шейпваш САМО изходящия трафик от интерфейса, т.е. ако искаш да ограничиш UL трябва да сложиш същия шейпър и на интернет интерфейса и да го съобразиш със скоростта на линията
ето и малък пример за операции с tc или как да направим shaper@home

Примерен код

#!/bin/bash # The Ultimate Setup For Your Internet Connection At Home # # # Set the following values to somewhat less than your actual download # and uplink speed. In kilobits DOWNLINK=400 UPLINK=2000 DEV=eth0 # clean existing down- and uplink qdiscs, hide errors tc qdisc del dev $DEV root    2> /dev/null > /dev/null tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null ###### uplink # install root HTB, point default traffic to 1:20: tc qdisc add dev $DEV root handle 1: htb default 20 # shape everything at $UPLINK speed - this prevents huge queues in your # DSL modem which destroy latency: tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k # high prio class 1:10: tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit burst 6k prio 1    # bulk & default class 1:20 - gets slightly less traffic, # and a lower priority:    tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit burst 6k prio 2        # both get Stochastic Fairness: tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10 tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10        # TOS Minimum Delay (ssh, NOT scp) in 1:10: tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip tos 0x10 0xff  flowid 1:10         # ICMP (ip protocol 1) in the interactive class 1:10 so we # can do measurements & impress our friends: tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 match ip protocol 1 0xff flowid 1:10        # To speed up downloads while an upload is going on, put ACK packets in # the interactive class:        tc filter add dev $DEV parent 1: protocol ip prio 10 u32 match ip protocol 6 0xff match u8 0x05 0x0f at 0 match u16 0x0000 0xffc0 at 2 match u8 0x10 0xff at 33 flowid 1:10                 # rest is 'non-interactive' ie 'bulk' and ends up in 1:20                                 ########## downlink ############# # slow downloads down to somewhat less than the real speed  to prevent # queuing at our ISP. Tune to see how high you can set it. # ISPs tend to have *huge* queues to make sure big downloads are fast # # attach ingress policer: tc qdisc add dev $DEV handle ffff: ingress                 # filter *everything* to it (0.0.0.0/0), drop everything that's # coming in too fast:                 tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1 tc class add dev $DEV parent 1:1 classid 1:90 htb rate 256kbit ceil 800kbit burst 100k tc class add dev $DEV parent 1:1 classid 1:100 htb rate 256kbit ceil 256kbit burst 150k tc class add dev $DEV parent 1:1 classid 1:200 htb rate 128kbit ceil 128kbit burst 15k tc class add dev $DEV parent 1:1 classid 1:201 htb rate 64kbit ceil 320kbit burst 15k tc class add dev $DEV parent 1:1 classid 1:300 htb rate 64kbit ceil 800kbit burst 15k tc class add dev $DEV parent 1:1 classid 1:30 htb rate 1mbit ceil 1mbit burst 15k tc class add dev $DEV parent 1:1 classid 1:20 htb rate 2mbit ceil 2mbit burst 15k #wsichko ogranicheno U32="tc filter add dev $DEV protocol ip parent 1:0 prio 1 u32" #$U32 match ip src 192.168.1.1/32 match ip dst 192.168.0.0/24 flowid 1:90 #$U32 match ip src 192.168.1.1/32 match ip dst 192.168.0. ##OFFICE #borkata $U32 match ip src 0/0 match ip dst 192.168.0.101/32 flowid 1:300 #pesho $U32 match ip src 0/0 match ip dst 192.168.0.102/32 flowid 1:300 #jip office $U32 match ip src 0/0 match ip dst 192.168.0.103/32 flowid 1:300

mrvoland, благодаря за изчерпателния отговор, но не ми станаха съвсем ясни някои моменти.

Значи, мисълта ми е следната. Има един интерфейс, за интернет и два към две вътрешни мрежи (да кажем 192.168.0.0/24 и 192.168.1.0/24). Ясно ми е как мога да укажа за всяка мрежа (т.е. за всеки интерфейс) колко трафик да се заделя и как да укажа при празна линия да се разпределя максимално трафика (примера с Гошко и Пенчо), за всеки интерфейс. Дотук добре, но не ми стана ясно как се прави същото това нещо м/у двата интерфейса.

Не знам дали се изразявам ясно. Да кажем, че имаме downlink 1024Kbps. Създаваме две опашки за всеки от вътрешните интерфейси - по 512Kbps. Как указваме, че ако на единия интерфейс няма никакъв трафик, неговите 512Kbps трябва да се преразпределят към другия.

Всъщност въпроса ми може да се формулира така - как постъпваме ако Гошко и Пенчо са интерфейси?

Иначе основните неща са ми ясни - че се shape-ва на малко по-ниска скорост и че може да се shape-ва само изходящ трафик.

Пак благодаря за отговора.

П.С.: Примера, който си пуснал да кажа - не съм го разглеждал подробно. Ще го погледна малко по-късно.

Пробва ли IMQ-то?
Че, честно казано и на мен ми се ще някой да сподели как върви това чудо - има ли прблеми при инсталацията, при ползване, проблеми с iptables, tc и т.н.

Сорри, ако си се почувствал като лаб. мишка

IMQ-то върви добре, засега не се дъни при мен, макар че тестовата машина не е много натоварена и не знам как ще работи при голям брой клиенти. По отношение на инсталирането, пачвате ядрото, но внимавайте, ако ще правите NAT на същата машина - внимателно огледайте опциите за NAT към IMQ-то: AA, BB, AB, BA (A - after, B - before IMQ), защото може да се наложи да прекомпилирате отново ядрото (при мен така се получи и не намерих начин да променям реда на прехвърляне към IMQ интерфейса on the fly). Ще трябва да прекомпилитарте и tc пакета - намерете tc-latest, както и iptables, за да разбират от IMQ. След това всичко върви нормално (поне засега).
Best wishes!
Alex

VladSun, ако въпроса ти е към мен зададен - не, не съм.

В момента NAT/Shaping/etc правя с OpenBSD/PF/ALTQ, не с Linux/iptables/tc.

По-скоро ме интересуваше теоретично как стоят нещата, но вероятно си зависи доста от конкретната реализация и инструменти, с които се прави.

mrvoland, и на мен, както на Наркос, не ми става ясна твоята идея. Скрипта, който си дал в предния постинг, разглежда случая само с един интерфейс към потребителите. Ако имаш възможност, метни тук и някой скрипт, описващ случая с два интерфейса към потребителите (какъвто е случая на Наркос). Лично аз ще бъда щастлив да видя решение, неизползващо IMQ.
Best wishes!
Alex

еми... не знам как по-ясно да го обясня...
идеята е към пуровначалния клас да се закачи подклас и към него подподклас като структурата е дървовидна

напънете се да помислите логически как може да се разпредели трафика, знам че е трудно но като схванете идеята от там нататък ще е лесно

да точно така примера е за един интерфейс
просто исках да покажа как се създават класове и подкласове

ако има някой който може да го обясни с по-прости думи нека да заповяда аз определено не мога да го обясня по-просто

Не можеш да сложиш parent класа на eth0, и да да имаш листо към него, което се намира на друг интерфейс ... поне аз доколкото знам ...
За това е направен IMQ ...

Напълно съм съгласен с VladSun - не можеш да си мешаш интерфейсите, както си искаш. А по отношение на създаването на класове и подкласове - няма спор, така е, но това е извън темата, пък и не е интересно. Още повече, че Наркос иска да направи това на *BSD. Аз не съм се качвал сериозно на *BSD, затова се въздържам да давам акъл там, единственото, което мога да кажа е, че ако това разпределяне на трафика му е жизнено необходимо и няма как да стане с *BSD, да ползва Линукс с IMQ пач.
P.S. По отношение на първия си постинг, извинявам се, че донякъде съм ви подвел (неволно) - tc пакета няма нужда от пачване, за да работи с IMQ - само iptables.
Best wishes!
Alex

съжалявам alex нямам голям опит с BSD за това се опитах да обясня само идеята как може да стане а реализацията оставям на вас...
ако съм подвел някого то било е неволно

Значи, вече изобщо не ми е ноебходимо да я правя тая врътка, т.к. вече интерфейса ми е един. :)

Въпроса ми беше по-скоро принципен.

Относно слабите машинки - определено има такъв момент със задъхването. В момента машината, която се занимава с NAT/shaping/etc. е 486DX2/66MHz - доста и е трудно и ще трябва да я сменям скоро. :)

Погледни http://www.linux-bg.org/cgi-bin....t=11231

при мен *определено* олекнаха нещата

Аха, гледал съм я тая тема. Като имам време ще й хвърля още един по-задълбочен поглед.

10x