Как лучше орган-ть шлюз на PFS
-
В вашем случае смысла создавать новые интерфейсы нет. Интерфейсы пришлось бы создать если все устройства бы были в одной физической сети на втором уровне и широкой маской IP (/16)
Дочерние очереди есть только в планировщике HFSC. Там сумма дочерних очередей вроде должна быть 70% от родительской.
@sundoom:В моем понимании логика такая: Сначала все пакеты попадают по самому верхнему правилу (режется по минималке - 30% от 128Кбит), затем по мере следования сверху вниз, если пакет попадает под какое-то из следующих правил, допустим, пакет попал под правило c очередью Office2 (более приоритетное), то он уже режется 512Кбит, а там попадает в следующее правило с дочерней очередью и т.д.
Логика тут проще - применяется последнее совпавшее правило.
-
Кстати, здесь небольшая опечатка, кто не догадался:
ID Proto Source Port Destination Port Gateway Queue
* * * * * * Other_traffic
* 172.15.0.0/24 * * * * Osnovnoi
* 172.15.1.0/24 * * * * Office1
* 172.15.2.0/24 * * * * Office2
* 172.15.3.0/24 * * * * Office3
* 192.168.0.0/24 * * * * Office4В общем вопрос поставлю проще. Как пустить разные подсети (удаленные офисы) через Trafic Shaper на PFSense, у которого 1 LAN (шлюз для DSL-модемов в удаленных офисах)? Выше я описал способ через задание дочерних очередей (подсетей) для LAN. Но такой способ очень громозкий для администрирования и описание правил. Может есть способ проще, например, создание вирт. сетей.
P.S. PFSense крутится на виртуалке. -
А каков смысл этого действия с шейпером? Если в удаленных офисах лимит скорости на уровне канала, то при Ваших 5 мегабитах они физически не смогут ничего сверх своей нормы получить. Какой смысл в шейпере?
-
Смысл таков. Если организовать в качестве дочерних очередей для LAN, то создается допустим дочерняя очередь с шириной канала, например, 512Кбит, а в ней другие дочерние очереди по протоколам, портам (как мне надо). Правилами привязывается подсеть к своей дочерней очереди. А LAN в этом случае должна быть равна или больше суммы всех дочерних очередей (подсетей со своими каналами). ТОлько тут ограничение на семь дочерних очередей (значит всего 7 подсетей) согласно наличию всего 7 приоритетов для HFSC.
Я думаю должно быть более простое и удобное решение. -
А причем здесь приоритеты для HFSC к количеству подсетей? Мне кажется, или вы чего-то не понимаете?
Зачем Вам иерархия по подсетям? Общие скорости на канал уже ограничены физически.
Если хотите регулировать какой-то вид трафика Интернет - Удаленный офис, просто создайте отдельные очередь и правила для этого трафика.ACK_common
Hi_1
Lo_1
Hi_2
Lo_2
… -
Наверно я не совсем доходчиво объяснил. В принципе у меня так и сделано как вы написали, но более усложненно. Насчет приоритетов - я не знаю есть ли возможность назначать один и тот же приоритет на несколько очередей. Как PFSense это понимает? Если же нельзя, то получается, что нельзя создавать более 7 (т.к. всего 7 приоритетов HFSC) очередей одного уровня. Но так как я создаю для каждой подсети свою очередь, то и получается, что сколько приоритетов, то столько и очередей для подсетей я могу прописать, т.е. не более 7. Но у меня 9 подсетей. Поэтому и задаю такие вопросы.
В итоге, у меня 2 вопроса:
1. Можно ли назначать один и тот же приоритет нескольким очередям?
2. КАК можно создать, например, вирт.интерфейс в PFSense и привязать его к определенной подсети, чтобы уже потом писать очереди шейпера для этого вирт.интерфейса? -
1. Да можно без ограничений.
2. Не понятно что значит привязать и виртуальные интерфейсы ? Есть VLAN, есть Virtual IP. -
Я приведу аналогию.
Шейпер в пф, это ведро в которое льется трафик входящего канала. Ваши правила - это дырки в ведре, через которые трафик выливается. Как только ведро заполнено, пакеты начинают отбрасываться (дропаются). Размер ведра обычно меньше скорости входящего канала (для эффективной работы).
Задача шейпера - не давать ведру переполняться. Но если ведро переполнилось, то правилами задаются приоритетные дырки, через которые трафик надо выпускать в первую очередь (и доля трафика вливающегося в ведро для этих дырок постепенно будет расти, а для остальных уменьшаться). Но правила, повторяю еще раз, делаются для дырок - исходящих каналов.
Если сделаете много интерфейсов, то вместо одного ведра получите несколько, которые наполняются независимыми входящими каналами.
Но как тут уже раньше писали, у вас есть физическое ограничение канала и канал этот только один. И независимых входящих каналов нет. Резать его еще самому на куски дополнительными интерфейсами особо смысла нет (но можно если хотите).
Все что вы можете, это правилами регулировать дырки в ведре (ваши подсети) чтобы оно не переполнялось.
Все это делается только если есть четкий план приоритета, если его нет - то шейпер в вашем случае не нужен. -
Nomeron, спасибо за доходчивое разъяснение. Как вы написали, в принципе, так я и полагал и сделал с некоторыми оговорками.
Но для интереса, а как можно было бы разделить один физический канал на несколько кроме использования VLAN и подключения дополнительных сетевых карт? -
Nomeron, спасибо за доходчивое разъяснение. Как вы написали, в принципе, так я и полагал и сделал с некоторыми оговорками.
Но для интереса, а как можно было бы разделить один физический канал на несколько кроме использования VLAN и подключения дополнительных сетевых карт?Alias-ми для подсетей (диапазонов адресов).
