Чем лучше распределить полосу?

[Platinum]

Доброй ночи! :) Возникла такая задача:

Имеем канал между двумя точками, полосу в 600 мбит, приходящий на главный маршрутизатор (ОС FreeBSD 7.2).

[%client_1%]-----|

[%client_2%]-----|----[ROUTER_2]-----------600mbps-----------[ROUTER_1]-----{....}

[%client_3%]-----|

Далее маршрутизатор "прокидывает" это канал во внутреннюю подсеть, т.е. имеем НАТ, в свою очередь во внутренней сетки стоят 2 сервера и один маршрутизатор. Нужно реализовать ограничение полосы для этих "клиентов", как по входящей, так и исходящей скорости. Касаемо входящего траффика, требуется разделить полосу на несколько частей:

1) %client_1% - гарантированная полоса входящая до 445 мбит, если нет других клиентов (они не грузят канал), отдаем всю свободную полосу, при этом если канал загружен, имеем приоритет, следующий за %client_2% .

2) %client_2% - гарантированная полоса входящая 155 мбит, если нет других клиентов (они не грузят канал), отдаем всю свободную полосу, при этом если канал загружен, имеем наивысший приоритет из всех трех клиентов.

3) %client_3% - минимально гарантируемая полоса входящая 25 мбит, максимальная 40 мбит, ночью до 50 мбит, при этом если канал загружен, имеем приоритет, следующий за %client_1% .

C %client_3%, часть траффика составляет VoIP, который должен пропускаться на основе QoS в первую очередь, в независимости от всех остальных правил нарезки.

Возможно ли построение таких правил? Чем лучше реализовать данные правила, чтобы наиболее оптимально для загрузки системы нарезать полосу? Возможно ли это сделать на основе pf (на нем реализован нат, хотелось бы все иметь в одном месте)?

 

Заранее спасибо :)

Edited July 17, 2009 by Platinum

[photon]

На pf/ALTQ это можно реализовать с помощью дисциплины CBQ или HFSC. В PF FAQ есть подходящий пример. Смену правил по времени, естественно, нужно делать с помощью cron. Кстати говоря, у вас не сходятся суммарная полоса пропускания и общая ширина канала: 445+155+25 = 625. Нужно нарезать с запасом в 1--3%, т.е. чтобы в сумме у всех было не более 594 Мбит.

[Platinum]

Спасибо) Действительно, с полосой немного ошибся, там 425 должно было быть. По поводу HFSC посмотрел маны, вот там написано "You can also queue data on the return trip on an external stateful connection. Remember you can _not_ queue data coming into the box, only going out." Т.е. как я понимаю, входящий "запрошенный" трафик, по его возвращению мы можем поставить в очередь. Но входящий, который мы не запрашивали - нет. Может ли это создать какие то дополнительные проблемы? Как я понимаю, например, в случае если один из серверов - веб сервер, нельзя будет контролировать запросный трафик к нему? И чисто теоретически можно не только частично забить входящую полосу паразитным трафиком, но и если не установлен лимит одновременных подключений с одного адреса, тот сервер может стать уязвимым, как при DDoS атаке?

Edited July 18, 2009 by Platinum

[photon]

Спасибо) Действительно, с полосой немного ошибся, там 425 должно было быть. По поводу HFSC посмотрел маны, вот там написано "You can also queue data on the return trip on an external stateful connection. Remember you can _not_ queue data coming into the box, only going out." Т.е. как я понимаю, входящий "запрошенный" трафик, по его возвращению мы можем поставить в очередь. Но входящий, который мы не запрашивали - нет. Может ли это создать какие то дополнительные проблемы? Как я понимаю, например, в случае если один из серверов - веб сервер, нельзя будет контролировать запросный трафик к нему? И чисто теоретически можно не только частично забить входящую полосу паразитным трафиком, но и если не установлен лимит одновременных подключений с одного адреса, тот сервер может стать уязвимым, как при DDoS атаке?

Вы теорию подучите сначала. Это утверждение относится не к HFSC, а к шейпингу вообще. Нельзя добиться гарантированной полосы пропускания для входящего трафика из-за того, что размер и задержка у входящих пакетов непредсказуемы. Можно ограничивать лишь пакетрейт входящего трафика. Для роутера этот вопрос решается очень просто: правила создаются на двух интерфейсах, тогда трафик в обоих направлениях будет обрабатываться как исходящий.