Здравейте,
моята задача е следната :

имам засега две мрежи клас С (/24), който се NAT-ва навън през едно
реално IP. Своевременно имам и транспарентно прокси с филтър за
съдържание, през което редиректвам заявки към порт 80.
На външен интерфейс имам мейлсървър, кешираш DNS сървър. Също така
имам два VPN тунела до други два от офисите ни. През този гейт излиза
и VoIP гейт.

Задачата като начало я сведох до разпределяне на канала на две равни
части за двете мрежи, като се опитах като е свободен той да се взема
изцяло от която и да е от тях.

$cmd_shape pipe 1 config bw 950kbits/s //при един мегабит връзка съм
сложил 95% //
$cmd_shape queue 1 config pipe 1 weight 50
$cmd_shape queue 2 config pipe 1 weight 50
$cmd 1 queue 1 ip from not 192.168.0.0/16 to 192.168.10.0/24
$cmd 1 queue 2 ip from not 192.168.0.0/16 to 192.168.20.0/24

Това обаче разпределя трафик поравно, ако има закачени по един
потребител от двете мрежи.Когато има задачени примерно трима - трафика
се дели поравно на тримата.
Понеже на външния интерфейс пакетите вече са с реалното ми IP
маскирани, явно трафик контрола се прави за вътрешните адреси.
Прочетох доста материали за трафик контрол, но някой неща като това с
поравното разпределяне на трафика м/у две мрежи не проумях.

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

1. VoIP
2. VPN тунелите
3. DNS server
4. NTPdate
5. SMTP server
6. HTTP/FTP

Мисля на част от хостовете, където нямат ограничения за дърпане да
сложа нисък "weight", както и лимит на конекциите към http/ftp сървъри.

Искам съвет дали планираната схема е добра, ако може нещо да се
оптимизира или направи като подобрение - ще се радвам на всяко мнение.
Ясно ми е, че нещата ще станат само като се попробват, но ме
интересува дали така се прави като цяло - концепцията.

Благодаря предварително на всички!

P.S. бях писал е мейлинг листата на freebsd-users така , че сорри на тези за които се повтарям. Там колегите споменаха , че почти няма избор и трябва да се премине към PF+ALTQ.Исках все пак да сондирам мнение преди да гледам другите варианти.

Ами като гледам нещата които искаш, ще трябва да ползваш pf/altq, просто дъминет е за друг тип шейпъри.

Нанайси нема стане.

Това, което искаш да се случи, се прави с маска на queue-то - конфигурираш един pipe и само едно queue, с маска dst-ip 0x0000ff00, след което пускаш входящия трафик и за двете подмрежи през това queue. По същия начин pipe и queue и за изходящия трафик.

На края на man ipfw пише за маските на traffic shaper-а, но в примерите не е посочено добре. Гарантирам, че работи, защото на 4.х дълго време съм действал така.

Все пак - присъединявам се към мнението, че е по-добре да минеш към pf.

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

ALTQ е т.нар. алтернативна опашка. Т.е. въпросът ми е дали може да се ползва съвместно с ipfw rules за да използвам нейната функционалност.
PF е адски добър - ползвал съм го и съм чел доста за него.Проблемът е , че не искам да пипам машините, където има настроени ipfw rules. PF е интегриран с ALTQ, което му е предимството.
Другото, което малко ме притеснява е , че PF/ALTQ се опитаха да ги merge-нат в дървото на FBSD около 5.2.1 - от тогава следя мейлинг листата и има доста проблеми, които излизат специфични от FBSD като OS.
Т.е. мислех, че dummynet/ipfw е доста по-"mature". Не съм предполагал, че няма имплементирани тези функции. Иначе според мен доста лесно/чисто се прави трафик контрол с dummynet (стига да ти трябват точно тези неща, които предлага).

А и едно от нещата, поради които вече съм се замислил за новите машини стена/рутер/... да са в PF, е че NAT се прави на ниво ядро и няма превключване към userspace демон, както е със IPFW/NATD. Доста бях учуден защо така е решено, но работи и върши работа.
Както са написали в някой туториали / това било защото FBSD e мощна станция, сървър за приложения и т.н., за което не било необходимо да се имплементира nat в GENERIC ядрото/.

ALTQ не можеш да управляваш с ipfw.
Може да си пуснеш pf и ipfw едновременно на машината, само не питай как точно ще вървят пакетите между тях .. ако намериш някъде paper по въпроса - дерзай :)

Иначе твоя проблем нали ти го написах как става с ipfw ..

ipfw никога не е било върха на сладоледа - вярно е, че върши работа, но в конкретни случаи - не добре. Простичко е за найстройка и е мощно, но много неща му липсват и затова отдавна се търси с какво да бъде заместено, тъй като е ясно, че няма да бъде оправено.
Първо този заместител беше ipfilter, но сега вече е общоприет факта, че OpenBSD са разработили много добър firewall и е глупаво да се открива топлата вода, след като те вече са се наиграли с джакузито и продължават нататък.

pf всъщност е в дървото на FreeBSD още от 5.0, но не с всичките си възможности. Проблеми се появяват и това е неизбежно, но можеш да си сигурен, че това е firewall-ът, по който ще се работи най-много. За справка - и сега са известни неприятни проблеми с ipfw, въпреки че е много улегнало и стабилно.

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

Да съгласен съм с по-голяма част от думите ти.

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

При следващото имплементиране на стена/рутер/шейпър ще съм подготвен да го имплементирам с pf/altq и явно за в бъдеще ще е добре да се ориентирам към миграция.Трябва да си призная, че съм ползвал pf в/у OBSD и мисля, че е страхотен /не съм правил трафик контрол обаче/, но някакси не исках да го възприема като част от FBSD - опитах с неговите си средства, но за жалост са по-слаби в някои места. Иначе от OBSD/pf мислех, преди да го merge-нат в 5.0 клона, че става най-добрата стена и най-интуитивна по настройка.

Благодаря още веднъж!