Изпечатай

[Hapkoc]

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

Идеята е следната:
                            ____
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-ване се определя скорост за интерфейс, но моите познания са доста начални в тая област, така че ще замоля някой по-запознат да ме осветли. '>

[VladSun]

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

[Hapkoc]

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

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

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

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

[Hapkoc]

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

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

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

[Hapkoc]

да, вярно :)

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

[roshisa]

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.

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

[mrvoland]

можеш да си шейпнеш всички интерфейси, в това ограничение няма '>
за да ти е равномерен шейпъра за 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

[Hapkoc]

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

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

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

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

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

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

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

[VladSun]

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

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

[alex_c]

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

[Hapkoc]

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

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

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

[mrvoland]

Цитат (Hapkoc @ Дек. 09 2005,01:36)

mrvoland, благодаря за изчерпателния отговор, но не ми станаха съвсем ясни някои моменти. '> Значи, мисълта ми е следната. Има един интерфейс, за интернет и два към две вътрешни мрежи (да кажем 192.168.0.0/24 и 192.168.1.0/24). Ясно ми е как мога да укажа за всяка мрежа (т.е. за всеки интерфейс) колко трафик да се заделя и как да укажа при празна линия да се разпределя максимално трафика (примера с Гошко и Пенчо), за всеки интерфейс. Дотук добре, но не ми стана ясно как се прави същото това нещо м/у двата интерфейса. Не знам дали се изразявам ясно. Да кажем, че имаме downlink 1024Kbps. Създаваме две опашки за всеки от вътрешните интерфейси - по 512Kbps. Как указваме, че ако на единия интерфейс няма никакъв трафик, неговите 512Kbps трябва да се преразпределят към другия. Всъщност въпроса ми може да се формулира така - как постъпваме ако Гошко и Пенчо са интерфейси? '> Иначе основните неща са ми ясни - че се shape-ва на малко по-ниска скорост и че може да се shape-ва само изходящ трафик. Пак благодаря за отговора. '> П.С.: Примера, който си пуснал да кажа - не съм го разглеждал подробно. Ще го погледна малко по-късно.

ами '> лесно е като помислиш логически как да стане '>
parent, subparent, subsubparent можеш да създадеш

ахх... как мразя да рисувам с ASCI '>


                  -(subparent1) eth1  споделено
                 |
parent (internet) eth0 или максимума на DL
                 |
                  -(subparent2) eth2  споделено

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

долкото знам бтк по този начин споделя скоростта между потребителите но може и да греша

схвана ли мисълта че пожеш да слагаш и подподкласове на подкласа '> ? т.е. можеш спокойно да ги разклониш...

малко ми е късно в момента но това между Пешо и Гошо също може да се направи просто малко повече въображение

п.п. само внимавай с многото класове и подкласове че на бавна машинка почва да се зори да смята трафика '>

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