Мрежови възможности на BSD и Linux

[Networker]

Здравейте,

първо искам да кажа, че целта на тази тема е не да образува два блока - за BSD или за Linux.

 

От доста години използвам не професионално Debian и нямам почти никакъв опит с BSD. От скоро започнах да търся някаква алтернатива на Debian или на Linux като цяло. В полезрението ми попадана FreeBSD. Прочетох доста статии за разликите между BSD и Linux. И забелязах, че едните казват само BSD, а другите само Linux.

 

А защо търсиш алтернатива на Дебиан - нещо конкретно не ти се получава или просто за спорта. Не си написал и какви параметри очакваш да покриеш (сесии, пакети в секунда, скорости, services на него и др.).

 

Темата е интересна, но отговора за BG по-скоро е - всеки ще си реализира нещата според възможностите и знанията дори алтернативата да е по-добра.

 

 

Не искам да създавам лагери, но лично съм фен на Линукс, понеже с него съм започнал да се занимавам едно време, ако бях почнал с BSD вероятно щях да съм с него . За не особено големи мрежи едва ли има чак такава разлика между двете, макар че BSD носи на повече натоварване. От друга страна за Линукс има много опции за филтриране/маркиране на трафик и всякакви гаври с него, които често се налагат (особено за QoS) и тонове софтуер (с тонове бъгове ).

 

Според мен, ако се заложи на добър хардуер - по-новите Xeon-и, с по-нови чипсети на Интел за LAN, и двата варианта ще ти вършат добра работа и със сигурност са добра алтернатива (и много по-евтина) на скъпите решения на Cisco и събратята им.

 

Въпрос на мрежова организация и нужда, но на един Xeon 4 ядрен спокойно можеш да наредиш 1000+ потребителя (тествахме преди време с един колега от София - при тях на 8 ядрени редиха 12x "C" мрежи на 1 бр. PPPoE AC - ако няма някоя недомислица в настройките си работи на под 1/3 от възможностите).

Редактирано 3 Декември, 2013 от Networker

[mysticall]

Всичко започна преди окоро година, когато имахме някакви проблеми в мрежата и ни трябваше програма, която да прави основен мониторинг. Тогава се запознах с zabbix и предложих на нашия администратор, да я интегрира със ситемата, която използваме или някоя друга програма за мониторинг. Като може да се досетите, нещата не станаха както си ги представях, но това не ме спря и реших да променя и опростя zabbix, което беше голяма грешка (почти 25Mb php код). Бях чувал за php, но никога небях го виждал. Борих се геройски с zabbix и разбрах, че за функционалността на мониторинга, който искам да напрява, за основа трябва да имам някаква система, която да има достъп до клиентите, vlan-ните... Тогава започнах да пиша  идеята, че когато е готова, ще продължа с мониторинга.

 

Признавам, че научих много неща за линукс, но видях и големи недостатъци. Когато разучавах, шейпъра на линукс и търсех лек вариянт, който да не яде много ресурси балона се спука. Да има много голяма функционалност, но това е свързано с ресурси. Ако трябва с увеличаването на клиентите и трафика, да се подновява и хардуера малко се обезмисля функционалността на линукс-кия шейпър. В търсенето на лек и ефективен шейпър попадна на http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=386924398 и в момента IMSLU използва IPMARK за маркиране на трафика. Колегите, които са го пробвали в реална среда може да кажат, до колко сполучлив избор съм направил.

 

Малко информация за вариянта, на който се спрях за шейпър:

 

маркира изходящия трафик от мрежа 10.111.1.0/24

/sbin/iptables -t mangle -A FORWARD -s 10.111.1.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000

маркира входящия трафик от мрежа 10.111.1.0/24

/sbin/iptables -t mangle -A FORWARD -d 10.111.1.0/24 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000

 

Примерно имаме клиент, който използва IP адрес 10.111.2.2 и тарифен план 20Mbit-Download - 20Mbit-Upload

 

Download

/sbin/tc class add dev vlan19 parent 1: classid 1:0202 htb rate 20480Kbit

/sbin/tc qdisc add dev vlan19 parent 1:0202 handle 0202 sfq perturb 10

 

Upload

/sbin/tc class replace dev eth1 parent 1: classid 1:0202 htb rate 20480Kbit

/sbin/tc qdisc add dev eth1 parent 1:0202 handle 0202 sfq perturb 10

 

Търсенето на лек и ефективен вариянт на линукс-ки шейпър, породи някои противоречия в мен. Започнах да се замислям, дали няма да е добре системата да работи и под FreeBSD и дали там нещата не са по-добре. Наскоро проведохме разговор с нашия администратор, който ми обясни, че не използва маркиращи правила за прихващане на пакетите от tc, а използва tc filter правила за съответния IP адрес и че по начина, който съм направил нещата ще имам неприятности. Питах го какво е мнението му за FreeBSD, обесни ми че няма смисъл да си губя времето и че има някои специфични неща, които не могат да се направят с *BSD.

 

Така започна тази тема и вече знам, че FreeBSD е това което търся.

Редактирано 3 Декември, 2013 от mysticall

[111111]

А как седи положението с това творение
http://www.debian.org/ports/kfreebsd-gnu/

[computer]

за основа трябва да имам някаква система, която да има достъп до клиентите, vlan-ните... Тогава започнах да пиша  идеята, че когато е готова, ще продължа с мониторинга

 

Така започна тази тема и вече знам, че FreeBSD е това което търся.

 

аз писах една малка системка за контрол на потребителите на freebsd и пърл за едни познати. Като цяло има супер много подобен софт, кой от кой по-зле, за това прецених че вместо да преправям нещо, ще ми отнеме много по-малко време да напиша хубава изчистена система от нула точно според изискванията и за около седмица с основна функционалност - управление на свободни/заети ип адреси, шейпинг, раздаване на ип по dhcp, спиране/пускане на интернет, и екстрата да имаш по няколко разрешени мак адреса за 1 ип.

Ха сега някой да ми каже колко време щеше му отнеме да го направи на циско рутер това

 

Във Freebsd отдавна има много екстри по шейпърите, но от няколко години за шейпене на неограничен брой различни тарифи (скорости) всичко което се използва е

2 правила във firewall и 2 таблици - това ако искаш да шейпиш входящ и изходящ и то ако са на различни скорости иначе само една таблица ти трябва .

 

Много от нещата по маркиране и гледане на ToS и QoS които липсваха от много години започват да се появяват къде във firewall, къде като нетграф модули или схеми за нетграф - типичен пример е блокирането на скайп на L7 през нетграф, което със сигурност вади много по-голяма производителност от линукския вариант

Редактирано 4 Декември, 2013 от computer

[mysticall]

Притеснява ме факта, че "Clang Replacing GCC in the Base System", http://www.h-online.com/open/news/item/FreeBSD-10-will-be-using-Clang-instead-of-GCC-1575954.html. FreeBSD разработчиците имат основателни причини, за тази промяна, но как ще се отрази това на производителността на системата. В интернет има доста теми по-въпроса, от които се разбира, че за момента кода компилиран с LLVM е по-бавен в сравнение с GCC.

[Networker]

Всичко започна преди окоро година, когато имахме някакви проблеми в мрежата и ни трябваше програма, която да прави основен мониторинг. Тогава се запознах с zabbix и предложих на нашия администратор, да я интегрира със ситемата, която използваме или някоя друга програма за мониторинг. Като може да се досетите, нещата не станаха както си ги представях, но това не ме спря и реших да променя и опростя zabbix, което беше голяма грешка (почти 25Mb php код). Бях чувал за php, но никога небях го виждал. Борих се геройски с zabbix и разбрах, че за функционалността на мониторинга, който искам да напрява, за основа трябва да имам някаква система, която да има достъп до клиентите, vlan-ните... Тогава започнах да пиша  идеята, че когато е готова, ще продължа с мониторинга.

 

Не че нещо, но има 10-ки готови или полу-готови решение ако говорим за чист мониторинт, ако става дума за билинг - и там има, но рядко пасват без преправяне. Това изглежда много времеемко и не особено смислено - освен ако времето не е проблем. Без да се обиждаш, но звучи като - не успях да си конфигурирам "XX" service в Windows и реших да го пренапиша.

 

 

Признавам, че научих много неща за линукс, но видях и големи недостатъци. Когато разучавах, шейпъра на линукс и търсех лек вариянт, който да не яде много ресурси балона се спука. Да има много голяма функционалност, но това е свързано с ресурси. Ако трябва с увеличаването на клиентите и трафика, да се подновява и хардуера малко се обезмисля функционалността на линукс-кия шейпър. В търсенето на лек и ефективен шейпър попадна на http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=386924398 и в момента IMSLU използва IPMARK за маркиране на трафика. Колегите, които са го пробвали в реална среда може да кажат, до колко сполучлив избор съм направил.

 

Малко информация за вариянта, на който се спрях за шейпър:

 

маркира изходящия трафик от мрежа 10.111.1.0/24

/sbin/iptables -t mangle -A FORWARD -s 10.111.1.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000

маркира входящия трафик от мрежа 10.111.1.0/24

/sbin/iptables -t mangle -A FORWARD -d 10.111.1.0/24 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000

 

Примерно имаме клиент, който използва IP адрес 10.111.2.2 и тарифен план 20Mbit-Download - 20Mbit-Upload

 

Download

/sbin/tc class add dev vlan19 parent 1: classid 1:0202 htb rate 20480Kbit

/sbin/tc qdisc add dev vlan19 parent 1:0202 handle 0202 sfq perturb 10

 

Upload

/sbin/tc class replace dev eth1 parent 1: classid 1:0202 htb rate 20480Kbit

/sbin/tc qdisc add dev eth1 parent 1:0202 handle 0202 sfq perturb 10

 

Какви недостатъци си видял при Линукс шейпърите ако може да споделиш - би било интересно предполагам?

Проблема при шейпърите в Линукс е тяхната имплементация - т.е. не е толкова просто и от там идват много грешки и недоразбирания от имплементиращите ги. По принцип е логично ако имаш повече извратени правила те да товарят системата повече при повече трафик/потребители (правила), но най-голямата грешка при имплементаторите е начина на маркиране на трафик за шейпване - аз както и много други съм минал по този път - има голяма разлика в производителността при грешна имплементация. Това не значи, че трябва да смениш платформата, а да четеш повече - едно време съм си загубил в годините поне 6 месеца (сумарно) четене, проби и грешки докато си докарам читав шейпър с QoS (особено QoS-а ми взе здравето и сумати и време - там основните разработчици на истинския DSCP опашки за Линукс ги "отказаха" да продължат проекта за Линукс и някак си случайно ги назначиха в CISCO).

 

 

 

Търсенето на лек и ефективен вариянт на линукс-ки шейпър, породи някои противоречия в мен. Започнах да се замислям, дали няма да е добре системата да работи и под FreeBSD и дали там нещата не са по-добре. Наскоро проведохме разговор с нашия администратор, който ми обясни, че не използва маркиращи правила за прихващане на пакетите от tc, а използва tc filter правила за съответния IP адрес и че по начина, който съм направил нещата ще имам неприятности. Питах го какво е мнението му за FreeBSD, обесни ми че няма смисъл да си губя времето и че има някои специфични неща, които не могат да се направят с *BSD.

 

Така започна тази тема и вече знам, че FreeBSD е това което търся.

 

Лекия и ефективен вариант не е мит, но е по-сложен за имплементиране. Мога да ти дам готово решение, но няма смисъл ако не си се пробвал сам. Прав е бил администратора (и добре те е насочил) - но извода не е да смениш платформата, а да си намериш грешката.

За пример (от преди 4-5 години) - стара машина P4/3GHz при общ трафик около 30Mbps с 128 потребителя на нея - твоя вариант при маркиране с iptables даваше лоад над 15!!!, същата машина по другия начин с 256 потребителя и 50-тина Mbps общ трафик - лоад ~0.6.

[kokaracha]

Това шейпър с QoS ми звучи много смешно особенно пък когато става въпрос за потребители а не за линк.

Пробламите с шейпърите в линукс доколкото си спомням беше броя правила и от там падане на производителността за сметка на товара Сега не знам как е.

Примерно колко правила ще имаш за 4 тарифи  със симетричен трафик и колко 1К потребителя ?

[Самуил Арсов]

Бях решил да не пиша повече в тази тема защото въпреки всичко тя се превърна във фен клуб на Левски и ЦСК. От една страна никой нищо технически не написа а само разни мнения и от друга, човека пуснал темата и на него много - много не му се разбира каква му е целта. С риск да стана банален все пак ще споделя.

 

Въпреки, че от птичи поглед изглежда, че в Линукс ограничението на скороста е някаква какафония това въобще не е така. Да, няма една голяма документация събрани howto но, исторически погледнато няма и как да има (това е друга тема). В Linux traffic shaper има няколко дисциплини и те напълно логично се използват в различни решения (мрежата не е просто нещо).

 

1. tc filter за download и ingress за upload. Класика в жанра, няма маркиране на пакети, правилата се прилагат на един интерфейс но важат за всички, шейпи в двете посоки, много точен, като недостатък харчи много ресурси но главния такъв е, че ingress няма опашка при повече правила става боза. Но до 100-на ип адреса (зависи от хардуера естествено) си остава незаменим, особенно за интерфейси VLAN, pptp, pppoe. С сглобен скрипт на bash съм шеипил около 400 pptp сесии, товареше но рабоше добре.

 

tc qdisc add dev eth0 root handle 1 htb default 10
tc class add dev eth0 parent 1: classid 1: htb rate 100Mbit

tc class add dev eth0 parent 1:1 classid 1:100 htb rate 20Mbit
tc filter add dev eth0 parent 1: protocol all prio 1 u32 match ip dst 192.168.1.2 classid 1:100
tc qdisc add dev eth0 parent 1:100 sfq

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol all prio 20 u32 match ip src 192.168.1.2 police rate 5Mbit burst 1Mbit drop flowid :100

2. IFB е съвременното решение на остарялото ingress. Няма маркиране, правилата са само на един интерфейс но важат за всички. Доста по леко работи на машина с много портове. Странното е, че рядко съм го виждал като имплементация може би защото няма никаква документация за него но според мен не му и трябва. Работи на простия принцип tc с filter, има го като незареден модул във всеки кърнъл. Като цяло работи добре но при много pps а не трафик товари найстина.

 

ip link set dev ifb0 up
 
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0
 
tc qdisc add dev eth0 root handle 1: htb r2q 625 default 65
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000Mbit
 
tc qdisc add dev ifb0 root handle 1: htb r2q 625 default 65
tc class add dev ifb0 parent 1: classid 1:1 htb rate 1000Mbit
 
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50Mbit
tc filter add dev eth0 parent 1: protocol all prio 1 u32 match ip dst 192.168.1.2 classid 1:10
tc qdisc add dev eth0 parent 1:10 handle 10: sfq
 
tc class add dev ifb0 parent 1:1 classid 1:10 htb rate 20Mbit
tc filter add dev ifb0 parent 1: protocol all prio 1 u32 match ip src 192.168.1.2 classid 1:10
tc qdisc add dev ifb0 parent 1:10 handle 10: sfq

3. IPMARK Ползва маркиране. Повечето администратори на мрежи си мислят, че маркирането на трафика товари машината неимоверно но придобиваики повече опит разбират, че е точно обратното. Маркирането е по леко защото iptables не е програма от user space на линукс кърнъла а е част от самият него и още по важното full state firewall което значи, че не следи пакет по пакет (което ще изисква огромно изчисление) а по връзката connection чез таблицата conntrack но да не задълбаваме сега. При долните правила shaper-a работи в пъти по леко от ingress и ifb.

tc qdisc add dev eth0 root handle 1: htb default 10
tc qdisc add dev eth1 root handle 1: htb default 10

iptables -t mangle -A POSTROUTING -d 192.168.1.2 -j MARK --set-mark 0x100
tc class add dev eth0 parent 1: classid 1:100 htb rate 20Mbit ceil 20Mbit burst 1Mbit
tc filter add dev eth0 parent 1: protocol ip prio 1 handle 0x100 fw classid 1:100
tc qdisc add dev eth0 parent 1:100 handle 0x100: sfq perturb 10

iptables -t mangle -A PREROUTING -s 192.168.1.2 -j MARK --set-mark 0x101
tc class add dev eth1 parent 1: classid 1:101 htb rate 5Mbit ceil 5Mbit burst 1Mbit
tc filter add dev eth1 parent 1: protocol ip prio 1 handle 0x101 fw classid 1:101
tc qdisc add dev eth1 parent 1:101 handle 0x101: sfq perturb 10

4. CLASSIFY "Класисифи" е същата схема на маркиране като IPMARK но разликата тук е, че отпада реда filter и така имаме доста по малко редове конфигурация. Търкалял съм около 1200 потребителя, 500-600 Mbits трафик на Q6600 с 40-70% load на CPU, много зависеше от броя connections в conntrack table а не от pps.

 

tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 1000Mbit

tc qdisc add dev eth1 root handle 1: htb default 10
tc class add dev eth1 parent 1: classid 1:1 htb rate 1000Mbit

iptables -t mangle -A FORWARD -d 192.168.1.2 -j CLASSIFY --set-class 1:100
tc class add dev eth0 parent 1:1 classid 1:100 htb rate 20Mbit burst 1Mbit
tc qdisc add dev eth0 parent 1:100 handle 100: sfq perturb 10
iptables -t mangle -A FORWARD -s 192.168.1.2 -j CLASSIFY --set-class 1:101
tc class add dev eth1 parent 1:1 classid 1:101 htb rate 5Mbit burst 1Mbit
tc qdisc add dev eth1 parent 1:101 handle 101: sfq perturb 10

5. IPMARK с hash. Скрипта по долу шейпеше същата конфигурация като в предишния пример. Четири секции за четири /24 публични мрежи и две /24 зад NAT. Във файла /etc/ipclient имаше описани твърдо 1524 ип адреса без да се променят ако не се използват. Машината не съм я виждал никога над 50% load на 500-600 Mbits трафик а имаше и една сесия BGP на нея. Тук е важно да се спомене за IPMARK с hash, е че де факто една /24 мрежа ползва само 4-ри правила и ядрото обработва само тях, останалите които влизат в hash тоест ip аддресите са си в правилото. Нещо подобно на address-list, което значи че за 1524 адреса аз ползвам 6 мрежи или 12 правила в tc ! Мисля, че е важно да кажа за тези които четат цифрите, като имам впредвид 500-600 Mbits трафик не става въпрос за сумарно а за едната посока само и то достигайки такива стоиности. Ако трябва да е сумарно e да кажем 800-900 Mbits

 

DEV1=vlan100
SPEEDIN=30Mbit
CEIL=1000Mbit
BURSTIN=2Mbit

tc qdisc del dev $DEV1 root
tc qdisc add dev $DEV1 root handle 1 htb default 1
tc filter add dev $DEV1 parent 1:0 protocol ip prio 1 fw

iptables -A POSTROUTING -t mangle -d 93.155.130.0/24 -j IPMARK --addr=dst --and-mask=0xff --or-mask=0x10100
IP=`grep -v # /etc/ipclient | grep speed1 | cut -d":" -f2 | grep 93.155.130 | cut -d"." -f4  | sort -nu`;
for IP in $IP; do
offset=$(printf "%d" 0x100)
id=$(printf "%x" $(($offset+$IP)))
tc class add dev $DEV1 parent 1:10 classid 1:0${id} htb rate $SPEEDIN ceil $CEIL burst $BURSTIN
tc qdisc add dev $DEV1 parent 1:0${id} handle 0${id} sfq perturb 10
done;

Явно е, че всички показани варианти по горе имат предимства и недостатъци, явно е, че са приложими в различни решения. Като пример ще дам вариант 4. CLASSIFY. Тук имах 139 мрежи с /24. Така си го беше решил доставчика - беше нарязал ма мрежи и малките улички в резултат на което се случваше в една /24 мрежа да има 5 адреса за шейпене. Този вариант с CLASSIFY е неприложим за IPMARK с hash защото не може да се хешират повече от 128 мрежи и така нататък.

 

В моята мрежа отдавна няма Linux Shaper. Не защото не го разбирам, не защото не го искам, не защото искам да съм модерен а защото ползвам готово решение с Mikrotik което си е чисто хеширане. Ясно е, че всички пройзводители от Mikrotik нагоре позлват подобна система за шейпене иначе реално е лудост да не го правиш от 1000 адреса нагоре. Предполагам, че ще има любобитни как става в две тарифи:

 

/ip firewall mangle
add action=mark-connection chain=forward comment=50Mbits new-connection-mark=50M src-address-list=50M
add action=mark-packet chain=forward connection-mark=50M new-packet-mark=50M passthrough=no
add action=mark-connection chain=forward comment=70Mbits new-connection-mark=70M src-address-list=70M
add action=mark-packet chain=forward connection-mark=70M new-packet-mark=70M passthrough=no

/queue type
add kind=pcq name=PCQ_down_50M pcq-classifier=dst-address pcq-rate=50M
add kind=pcq name=PCQ_up_30M pcq-classifier=src-address pcq-rate=30M
add kind=pcq name=PCQ_down_70M pcq-classifier=dst-address pcq-rate=70M
add kind=pcq name=PCQ_up_70M pcq-classifier=src-address pcq-rate=70M

/queue tree
add name=Download parent=ether1 priority=1
add name=Upload parent=ether2 priority=1
add name=down_50M packet-mark=50M parent=Download queue=PCQ_down_50M
add name=30M packet-mark=50M parent=Upload queue=PCQ_up_30M
add name=down_70M packet-mark=70M parent=Download priority=1 queue=PCQ_down_70M
add name=70M packet-mark=70M parent=Upload priority=1 queue=PCQ_up_70M

след което се добавят адресите в address-listata

/ip firewall address-list
add address=93.155.162.2 list=50M
add address=93.155.162.3 list=50M
add address=93.155.162.4 list=50M
add address=93.155.162.5 list=70M
add address=93.155.162.6 list=50M
add address=93.155.162.7 list=50M
add address=93.155.162.8 list=50M
add address=93.155.162.9 list=50M
add address=93.155.162.253 list=70M
add address=93.155.162.254 list=70M

В този вариант на Mikrotik съм доволен и ресурса е достатъчен засега. В бъдеще ако главоломно скочи трафика което е малко вероятно мисля да мигрирам към Juniper M7. Имам нужните познания за това и ще е естествен технологичен процес който естествено ще се подплати от броя на клиентите

 

Последно искам да споделя моето мнение с човека пуснал първия пост. Моят съвет е ако наистина имаш ресурс да кодваш разни работи и имаш желание по добре драсни един билинг за free radius с Mikrotik например (може и с нещо друго разбира се), вероятноста да изкараш лаври е много по голяма. Дори го пусни в нета с някаква прилична сума като за Българи със support. Тогава със сигурност ще има развитие по този проект а и естествена финансова подкрепа от която ще имаш нужда.

 

За хората занимавали се малко повече с мрежи и е ясно, че бъдещето на рутерите е в хардуерното ускорение, колкото и да не ни се иска x86 за рутер е една епоха която си отива с ненаписана история. Още повече, че ковчега в който Sisco и Juniper криеха тази технология с години вече е отворен. След Cavium Octeon CPU който е евтин MIPS 64 няколко пройзводителя пуснаха на пазара рутери за 200 лева да завъртат Gigabit с милион пакети посоката е ясна ...

разработчиците потриват ръце:

както от Linux лагера http://www.ubnt.com/edgemax

така и от BSD http://www.openbsd.org/octeon.html

Редактирано 12 Декември, 2013 от samyil

[mysticall]

Мисля, че се получи интересена тема, която ще е полезна и за други потребителите. Може би за администраторите, които имат дългогодишен опит с мрежи, ще им се стори, че няма нищо съществено, но ако се замислите за самото начало. От къде да започне човек, който иска да се занимава с мрежи и администриране, но няма опит, достъп до оборудване, трафик, потребители? Трябва ли всички да вървим по пътища, които не водят на никъде, за да го установим накрая?

 

Мисля, че всеки има какво да научи от другия, ако го иска.

 

Искам да поздравя samyil, не само поради участието си в тази тема, но и за статиите в http://itservice-bg.net/. Колко администратора биха споделили опита си по този начин?

След като прочетох с какви проблеми се е сблъскал samyil, какво е пробвал и какви са били резултатите, реших да се спра на шейпър с IPMARK. Ако нямаше подобна информация, сега щях  да се лутам напред и назад, без да предполагам доколко, ще работи.

 

Понякога е достатъчно да се даде само насока.

Към долния пост, напълно съм съгласен. Лично аз не искам готови решения и него препоръчвам. Когато имам насока, сядам и започвам да тествам, докато ми се изясни идеята, кое как работи и защо. Когато се уверя, че наистина работи, в същото време вече знам и как да го направя.

Ако някой като samyil, на който му се е налагало да администрира над 1к потребители, не беше споделил опита си, поне според мен това можеше да се направи с всеки описан метод в http://www.lartc.org/.

Редактирано 13 Декември, 2013 от mysticall

[Networker]

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

Човек, който иска да се занимава с мрежи, трябва да има най-малко теориятя - т.е. четене (опити на някое свое PC/рутер дори с 2 тестови users зад него), в Интернет данни много. Ако ще е Линукс: http://www.lartc.org/

 

Колегата по-горе е пропуснал да спомене за IMQ и u32.

[111111]

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

[MiPSus]

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

Само не ти видях примера

[111111]

Само не ти видях примера

Извинявай

http://mikrotik.axiom-pro.ru/library/QoS_Megis.pdf

http://wiki.mikrotik.com/wiki/Different_limits_for_Local/Overseas_traffic_for_3_bandwitch_rates_using_pcq_and_queue_tree

[mysticall]

Попаднах на една руска статия "http://habrahabr.ru/post/110616/", в която описват метод за създаване на високо производителен щейпър. Не ми стана ясна основната идея, но разбрах само че използват "Fast u32 hashing filter generator" - "http://vcalinus.gemenii.ro/?p=9", който създава U32 хеш филтър за много бързо мачване. Автора на статията твърди, че подобен шейпър може да обслужва над 5К потребители.

 

Предполагам, че това е метода, за който ми каза нашия администратор.

[Тодор Лазаров]

навремето писах по тази тема

 

 

Интересно ще е как е направен frontend-a на php не го намериш в този сайт

http://storinka.com.ua/projects/

Редактирано 15 Декември, 2013 от Тодор Лазаров