The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  правила/FAQ  поиск  регистрация  вход/выход  слежка  RSS
"Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от auto_tips (ok) on 09-Апр-12, 14:27 
Проблема приоритизации трафика, на мой взгляд, весьма актуальна. Интернет-канала много не бывает и на всех пользователей и сервисов локальной зачастую не хватает. Поэтому для нормальной работы Интернета требуется грамотное распределения полосы с учетом потребностей каждого из участников. Единственный раз, когда мне не понадобился QoS - это гарантированный провайдером канал в 20 Мбит/с в мир и 100Мбит/с - национальный. Но такое удовольствие не из дешевых, поэтому зачастую народ довольствуется ADSL-каналом с заявленной скоростью к клиенту до 5-10 Мбит/с.

Хочу заметить, что данная статья не предназначенная для новичков в сетевом администрировании в целом и в PF в частности. Читателю необходимо иметь минимальные навыки работы с сетями (понимать устройство пакета, знать что такое ТСР-флаги и т.д.), а также с пакетным фильтром PF. Не лишним будет прочесть официальный FAQ и man'ы. В основном цель этой статьи поделиться опытом, выслушать замечания и, возможно, улучшить свой вариант.

И так, постановка задачи: организовать доступ к сети Интернет. Грамотно распределить как входящий так и исходящий трафик с разделением канала для клиентов локальной сети и сервисов, запущенных на самом роутере (например, FTP-сервер, SIP-сервер и т.д.). В качестве роутера выступает сервер с ОС FreeBSD 9 c пакетным фильром PF.
Протокол FTP будет использоваться только в пассивном режиме, что немного упростит конфигурацию.

Для решения поставленной задачи необходимо пересобрать ядро и включить в него поддержку PF и ALTQ. Для задач, не требующих ALTQ, пересобирать ядро не обязательно. Можно просто подгрузить PF как модуль.

Добавляем в файл конфигурации следующие строки и пересобираем ядро. Описывать  каждую опцию не буду. В man 4 altq все есть.

   options HZ=1000

   device pf
   device pflog
   options ALTQ
   options ALTQ_CBQ
   options ALTQ_RED
   options ALTQ_RIO
   options ALTQ_HFSC
   options ALTQ_CDNR
   options ALTQ_PRIQ
   #options ALTQ_NOPCC #for SMP CPU

Лично я для боевого сервера пересобираю не только ядро системы, но и мир. Как это сделать, хорошо описано в Хендбуке и /usr/src/Makefile.

Для автоматического запуска PF при старте системы добавляем в /etc/rc.conf строки:

   pf_enable="YES"
   pflog_enable="YES"

Далее, собственно, сам конфигурационный файл пакетного фильтра. Возьмем самую простую реализацию роутера: один внутренний сетевой интерфейс и один внешний. Интернет канал подключен через ADSL-модем, работающий в режиме моста, т.е. подключение pppoe организовано средствами штатного ppp-клиента.

Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c.
На роутере запущен HTTP-прокси для прозрачного перенаправления WWW-трафика пользователей сети. Это сделано с целью блокировать метод CONNECT и принудительно направить другие виды трафика (например, торрент) в другие очереди с другим приоритетом. Я использую легковесный, но "шустрый" 3proxy (3proxy.ru). Кому важен кэш - используйте Squid или Apache Traffic Server.

Также перенаправляются все ДНС-запросы на сервер ДНС-провайдера. Это сделано с целью блокировки фишинговых и других зловредных сайтов, сайтов для взрослых, аплоадеры, соц. сети и т.д. и т.п. Некоторые компании так же предоставляет блокировку рекламных баннеров.

Весь исходящий трафик я разбил на следующие очереди:

- ДНС-запросы - очередь u_dns

- ТСР АСК-пакеты - очередь u_ack

- трафик с высоким приоритетом - очередь u_hipri

- трафик с нормальным приоритетом - очередь u_pri

- трафик с низким приоритетом - очередь u_lowpri

- весь остальной трафик - очередь u_other

- стандартная очередь - очередь u_std, одна очередь должна быть с опцией default, в которую попадает трафик, который не попадает ни под какое другое правило. В нашем случае это показатель правильности назначения очередей в правилах фильтрации. В эту очередь ничего не должно попадать.

Аналогичное деление трафика, идущего к клиенту локальной сети, только вместо u_* используется d_* обозначение.

Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP.
Данные, являющиеся ДНС-запросам и ТСР АСК-пакетами, для всех пользователей имеют свой высокий неизменный приоритет. Например, весь трафик от/к компьютера, относящегося к группе с низким приоритетом, будет обрабатываться с низким приоритетом, кроме ДНС и ТСР АСК.

Определяем макросы, что бы меньше текста в основной части конфигурационного файла.

   mst="modulate state"
   str="source-track rule"
   ext_if="tun0"
   int_if="rl0"

Таблица, в которую включены компьютеры трафик  к/от которых весь будет считаться с высоким приоритетом.

   table <pc_hipri> persist {10.11.1.2}

Аналогично для ПК с нормальным приоритетом.

   table <pc_pri> persist {10.13.1.2 10.13.1.10 10.13.1.13 10.13.1.14 10.13.1.15}

Таблица с адресами, доступ к которым блокируется.

   table <ban> persist file "/etc/pf.ban"

Таблица, с адресами клиентов, которым можно доверять.

   table <trust> persist {123.10.456.0/24 193.196.125.0/24}

IP-адрес системного администратора.

   table <me> persist {210.211.13.84}

IP-адреса SIP-провайдеров

   table <sip_peers> persist {212.15.65.122 75.16.127.118}

Конфигурируем опции пакетного фильтра, изменяющие его поведение. В нашем случае:

- не производится проверка на интерфейсе обратной петли;

- выставляем оптимизацию правил в basic;

- устанавливаем привязку состояний соединения (т.н. стейтов) к каждому интерфейсу;

- устанавливаем максимальное кол-во состояний. Если сетевых интерфейсов большое кол-во или большое кол-во клиентов в сети, возможно, потребуется скорректировать это значение в большую сторону.

   set skip on lo0
   set ruleset-optimization basic
   set state-policy if-bound
   set limit states 20000

Нормализация трафика (т.н. скрабинг). Срабинг позволяет значительно повысить безопасность файервола. В нашем случае выполняется нормализация трафика на внешнем интерфейсе, генерируется случайная последовательность в поле идентификации IP-пакета, устанавливается величина TTL=128, производится "дефрагментация" IP-пакетов, а также нормализация TCP соединений.

   scrub on $ext_if all random-id no-df min-ttl 128 fragment reassemble reassemble tcp


++ ALTQ.

Приоритизировать будем на всех физических сетевых интерфейсах. На внешнем - исходящий трафик, на внутреннем - входящий.
Выбор дисциплины - очень важный момент. Возможные варианты: priq, cbq, hfsc.

Я использую hfsc, т.к. важной чертой этого планировщика есть именно гарантирование полосы для конкретного пользователя/сервиса. Работа планировщика для нашего конкретного случая построена следующим образом: если в описании очереди указан дополнительный параметр realtime, то ей будет отдана указанная (realtime) полоса независимо ни от чего. Величина трафика свыше realtime будет рассчитываться исходя из величины bandwidth. Причем  bandwidth - не абсолютный параметр, скорее относительный.

Исходя из величин bandwidth каждой очереди рассчитывается величина трафика свыше realtime для каждой очереди пока не будет достигнут параметр upperlimit, который жестко ограничивает полосу. Приоритеты в планировщике hfsc не используются.

Помимо всех прочих параметров, hfsc имеет параметр qlimit - кол-во слотов, доступных очереди для сохранения исходящих пакетов, когда вся доступная полоса исчерпана. И только когда все слоты будут заняты, пакеты будут отбрасываться, что заставит клиента снижать скорость. Мы не будем использовать RED или ECN, вместо этого увеличим значение qlimit.

Назначаем очередь на внешнем интерфейсе. Величина bandwidth должна быть 96% от предоставляемой вышестоящим роутером. Здесь же перечисляем все дочерние очереди.

   altq on $ext_if hfsc bandwidth 800Kb queue {u_std,u_ack,u_dns,u_hipri,u_pri,u_lowpri,u_other}

Очередь по-умолчанию. Будет потреблять 25 кбит/с независимо ни от чего. Величина bandwidth 1Kb означает, что если канал будет полностью занят любой другой очередью или всеми, то очередь u_std практически ничего не получит свыше 25 кбит/с.
    
   queue u_std bandwidth 1Kb qlimit 50 hfsc (default realtime 25Kb)

Очередь u_ack - это ТСР АСК-пакеты, которые будут отправляться удаленному хосту с которого происходит загрузка по протоколу ТСР. Важно, что бы эти пакеты проходили без задержек. Для максимальной скорости от провайдеоа 4 Мбит/с требуется гарантированный канал в обратную сторону в размере 125 кбит/с.
    
   queue u_ack bandwidth 1Kb qlimit 200 hfsc (realtime 125Kb)

ДНС-запросы. Гарантированной полосы в 25 кбит/с вполне достаточно. Больше не нужно, поэтому bandwidth 1Kb
    
   queue u_dns bandwidth 1Kb qlimit 50 hfsc (realtime 25Kb)

Очередь с высоким приоритетом
    
   queue u_hipri bandwidth 300Kb qlimit 250 hfsc (realtime 200Kb)

Очередь с обычным приоритетом

   queue u_pri bandwidth 300Kb qlimit 400 hfsc (realtime 150Kb)

Очередь с низким приоритетом

   queue u_lowpri bandwidth 100Kb qlimit 100 hfsc (realtime 75Kb)

Очередь для всего остального трафика ТСР и UDP.

   queue u_other bandwidth 97Kb qlimit 50 hfsc (realtime 25Kb)

Назначаем очереди на внутреннем интерфейсе - приоритизируем входящий трафик. Провайдер отдает 5 Мбит/с, поэтому устанавливаем очередь inetq в размере 96%. Так же на внутреннем интерфейсе запущен ряд служб, например, локальный FTP, поэтому важно "не смешать" локальный трафик с Интернет-трафиком. Так как сетевая карточка 100Mbit, то выставляем значение bandwidth в 100Mb. Назначаем две очереди: одна - локальный трафик, вторая Интернет-трафик с дочерними очередями.

   altq on $int_if hfsc bandwidth 100Mb queue {etherq, inetq}

Очередь для локального трафика. В эту очередь будут попадать все пакеты, идущие от внутреннего сетевого интерфейса к пользователям локальной сети. Параметр upperlimit определяет максимальное значения для данной очереди. Заметьте, в эту очередь не будут попадать ответы, например, от WWW-сервера из сети Интернет. Эта очередь исключительно для локального трафика.

   queue etherq bandwidth 95Mb hfsc (upperlimit 95Mb)

Очередь для Интернет-трафика. В эту очередь будут попадать пакеты, идущие с сети Интернет. Имеет дочерние очереди по аналогии с внешним интерфейсом.

   queue inetq bandwidth 4800Kb hfsc (upperlimit 4800Kb) {d_std,d_ack,d_dns,d_hipri,d_pri,d_lowpri,d_other}
   queue d_std bandwidth 1Kb qlimit 50 hfsc (default realtime 25Kb)
   queue d_ack bandwidth 1Kb qlimit 50 hfsc (realtime 50Kb)
   queue d_dns bandwidth 1Kb qlimit 50 hfsc (realtime 25Kb)
   queue d_hipri bandwidth 1297Kb qlimit 500 hfsc (realtime 1000Kb)
   queue d_pri bandwidth 2000Kb qlimit 500 hfsc (realtime 2000Kb)
   queue d_lowpri bandwidth 1000Kb qlimit 500 hfsc (realtime 500Kb)
   queue d_other bandwidth 500Kb qlimit 500 hfsc (realtime 240Kb)

++ Правила трансляции локальных адресов (NAT).

Транслируются адреса, где источник - IP-адрес из любой подсети внутреннего интерфейса, а адрес назначения - любой, кроме IP-адресов из всех подсетей, подключенных к роутеру. Это могут быть как физические так и VPN-интерфейсы (tun, gif).
($ext_if) - в круглых скобках, т.к. IP-адрес внешнего интерфейса назначается динамически.

($int_if:network) и (self) в круглых скобках что бы в выводе pfctl -sn не было подстановки реальных адресов и сетей. Это удобно, когда у вас на внутреннем интерфейсе несколько алиасов и, соответственно, подсетей (как в моем случае).

   nat on $ext_if inet from ($int_if:network) to !(self) -> ($ext_if) port 1024:65535

Пользователей из группы pc_hipri и pc_pri пускаем в обход прокси. Я пускаю их напрямую, т.к. эти пользователи не нуждаются в контроле, а также специфическое ПО не работает в режиме прозрачного проксирования.

   no rdr on $int_if inet proto tcp from {<pc_hipri> <pc_pri>} to !(self) port 80

Правило редиректа, перенаправляющие все ДНС-запросы локальных пользователей на внешний ДНС-сервер. Это может быть Google или, лучше, ДНС-сервер компании, предоставляющей фильтрацию трафика посредством ДНС.

   rdr on $int_if inet proto {tcp udp} from ($int_if:network) to !(self) port 53 -> 193.58.251.251 port 53

Редирект на прокси-сервер.

   rdr on $int_if inet proto tcp from ($int_if:network) to !(self) port 80 -> 127.0.0.1 port 31280

Редирект на удаленный рабочий стол виндовой машины в локальной сети из сети Интернет.

   rdr on $ext_if inet proto tcp from any to ($ext_if) port 3389 -> 10.11.1.2 port 3389

Правила фильтрации трафика. Правила будем группировать в такой последовательности: действие, интерфейс, направление, протокол, адрес источника, порт источника, адрес назначения, порт назначения.

++ Антиспуфинг.

   antispoof quick for {$int_if lo0} inet

Блокируем не маршрутизируемые адреса.

   block in quick inet from no-route to any

Блокируем броадкасты.

   block in quick on $ext_if inet from any to 255.255.255.255

Блокируем IP-адреса, содержащиеся в таблице ban. Опция return возвращает TCP RST, что закрывает сразу соединение без таймаута. Полезно, когда блокируются адреса рекламных сетей, что позволяет браузеру нормально загружать странички без ожидания загрузки блокируемого контента.

   block return out quick on $ext_if inet from any to <ban>

Эти 2 правила определяют тип файервола: запрещено все, кроме явно разрешенного.

   block in all
   block out all

Собственно разрешающие правила.
Расположены в определенной последовательности, что важно с точки зрения производительности, а также ожидаемого эффекта.

Внутренний интерфейс.
Разрешаем ТСР-пакеты к интерфейсу обратной петли, на котором "слушает" прокси- сервер для организации прозрачного проксирования. Назначаем очереди. Мы не можем приоритизировать входящий трафик, только исходящий. В d_pri будут попадать пакеты, которые являются ответом от сервера к клиенту, таким образом мы регулируем скорость скачивания.

   pass in log quick on $int_if inet proto tcp from ($int_if:network) to 127.0.0.1 port 31280 queue (d_pri, d_ack)

Далее 3 правила, которые разрешают ТСР соединения на определенные порты на не локальные IP-адреса. Назначаются соответствующие очереди. Тегирование необходимо что бы потом на внешнем интерфейсе мы могли "отделить" его от остального трафика и направить в нужную очередь. Заметьте, опция quick не используется, поэтому эти правила нужно расположить в правильной последовательности: от менее ограничивающего к более, потому как без опции quick последнее совпавшее правило выигрывает, а не первое совпавшее.

Опция quick не используется т.к. при совпадении пакет будет назначен в очередь и пропущен и не дойдет до тех правил, которые описывают разрешения и приоритеты, основанные не на протоколах, а на адресах источника/назначения (в нашем случае это компьютеры из группы pc_hipri и pc_pri). Т.к. протокол ТСР, то так же добавляем очередь для ТСР АСК-пакетов. В качестве адреса назначения в правилах фигурирует !(self:network). Это значит, что только пакеты, не предназначенные ни к одному IP-адресу сетевых интерфейсов или IP-адресу из подсетей, подключенных к роутеру, будут разрешаться и, соответственно, тегироваться. Это, например, не даст подключиться к внешнему IP из локальной сети.

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        $mst queue (d_other d_ack) tag INET_OTHER

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port {20 21 25 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port 443 $mst queue (d_pri d_ack) tag INET_PRI

Далее 2 правила, которые будут срабатывать как для всех пользователей так и для тех, кто принадлежит к т.н. VIP-группе (pc_hipri и pc_pri). Поэтому тут используем опцию quick.

   pass in log quick on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port {22 3389} $mst queue (d_hipri d_ack) tag INET_HIPRI

   pass in log quick on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port 53 $mst queue (d_dns d_ack) tag INET_DNS

Следующие 2 правила, по-аналогии с TCP, описывают разрешения и очереди для протокола UDP. Так же их тегируем. Второе правило с опцией quick, т.к. оно должно срабатывать для всех категорий пользователей.

   pass in log on $int_if inet proto udp from ($int_if:network) to !(self:network) queue d_other tag INET_OTHER

   pass in log quick on $int_if inet proto udp from ($int_if:network) to !(self:network) \
        port {53 123} queue d_dns tag INET_DNS

Правило, разрешающее ICMP.

   pass in log on $int_if inet proto icmp from ($int_if:network) to !(self:network) queue d_lowpri tag INET_LOWPRI

Следующие правила, разрешающие трафик от клиентов, с высоким и нормальным приоритетом. Весь трафик будет считаться очень высоким (hipri) или высоким (pri) приоритетом (кроме ДНС и ТСР АСК). Здесь мы не указываем протокол, но указываем modulate state, который применяется только для ТСР. Это не будет ошибкой, PF достаточно "умный" и он подставит modulate state для протокола ТСР, и keep state - для всех остальных протоколов.

   pass in log quick on $int_if inet from <pc_hipri> to !(self:network) $mst queue (d_hipri, d_ack) tag INET_HIPRI

   pass in log quick on $int_if inet from <pc_pri> to !(self:network) $mst queue (d_pri, d_ack) tag INET_PRI

Разрешаем локальный Ethernet к внутреннему интерфейсу роутера.

   pass in quick on $int_if inet from ($int_if:network) to ($int_if) queue etherq

Теперь опишем разрешающие правила с внутреннего интерфейса роутера в локальную сеть. Если у вас нет редиректа с Интернета в локальную сеть или нет никаких серверов/клиентов, запущенных на самом роутере и требующих доступ в локальную сеть, то эти правила можно не добавлять.
Первое правило разрешает трафик с Интернета к указанному IP в локальной сети и назначает очень высокий приоритет входящего трафика. Это третье правило (первое - rdr, второе - разрешающее на внешнем интерфейсе) для редиректа (проброса) порта в локальную сеть.

   pass out quick on $int_if inet proto tcp from !(self) to 10.11.1.2 port 3389 queue (d_hipri d_ack)

Правило, разрешающее трафик от внутреннего сетевого интерфейса роутера в локальную сеть. Не важно какой протокол. Весь направляется в очередь etherq.

   pass out quick on $int_if inet from ($int_if) to ($int_if:network) queue etherq


Внешний интерфейс. Разрешающие правила для входящего трафика. Важно, для каждого входящего правило указывать максимальное кол-во стейтов, которые может создать правило. Это предотвратит исчерпывания всего лимита стейтов одним правилом в случае DoS атаки.
Последующие 6 правил разрешают входящие ТСР-подключения к определенным портам роутера, а также назначаются соответствующие очереди. Эти очереди будут приоритизировать не входящий трафик, а исходящий. Так же стоит обратить внимание на первые два правила, которые разрешают доступ к FTP серверу на роутере. Передача команд по 21-му порту будет направляться в очередь с большим приоритетом (u_pri), а данные - с меньшим (u_lowpri).

   pass in quick on $ext_if inet proto tcp from <trust> to ($ext_if) port 21 $mst (max 100) queue (u_pri u_ack)

   pass in quick on $ext_if inet proto tcp from <trust> to ($ext_if) port >=49152 $mst (max 100) queue (u_lowpri u_ack)

   pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 22 $mst (max 10) queue (u_hipri u_ack)

   pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 80 $mst (max 100) queue (u_pri u_ack)

   pass in quick on $ext_if inet proto tcp from <me> to ($ext_if) port 5900 $mst (max 10) queue (u_hipri u_ack)

Правило, разрешающее входящее подключение с сети Интернет (конкретно с адреса администратора), но не к интерфейсам роутера (внешнему в том числе), а к компьютеру в локальной сети к порту RDP.

   pass in quick on $ext_if inet proto tcp from <me> to !(self) port 3389 $mst (max 10) queue (u_hipri u_ack)

Следующее правило разрешает подключение с любого адреса сети Интернет к VNC-репитеру. В целях безопасности включен трекинг источника (source-track).

   pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 5500 $mst \
        (max 10,$str, max-src-nodes 2, max-src-states 3, max-src-conn-rate 3/60) \
        queue (u_hipri u_ack)


Следующие 2 правила разрешают подключения к определенным портам по протоколу UDP.

   pass in quick on $ext_if inet proto udp from any to ($ext_if) port 1194 (max 20) queue u_pri

   pass in quick on $ext_if inet proto udp from <sip_peers> to ($ext_if) port 5060 (max 20) queue u_hipri

Разрешаем пинг к внешнему интерфейсу.

   pass in quick on $ext_if inet proto icmp from any to ($ext_if) icmp-type echoreq (max 100) queue u_other

Внешний интерфейс. Разрешающие правила для исходящего трафика.
Следующие 5 правил разрешают исходящий трафик с внешнего интерфейса, который был помечен на внутреннем интерфейсе. Это исключительно данные, которые передаются в сеть Интернет от клиентов в локальной сети.

   pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_dns u_ack) tagged INET_DNS

   pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_hipri u_ack) tagged INET_HIPRI

   pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_pri u_ack) tagged INET_PRI

   pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_lowpri u_ack) tagged INET_LOWPRI

   pass out quick on $ext_if inet from ($ext_if) to any $mst queue (u_other u_ack) tagged INET_OTHER

И последние правила, разрешающие исходящие соединения с внешнего интерфейса. Это будет трафик непосредственно самого роутера. В целом приоритет этого трафика выше чем от клиентов в локальной сети.

   pass out quick on $ext_if inet proto tcp from ($ext_if) to any port 53 $mst queue (u_dns u_ack)
        
   pass out quick on $ext_if inet proto tcp from ($ext_if) to any $mst queue (u_pri u_ack)

   pass out quick on $ext_if inet proto udp from ($ext_if) to any port {53 123} queue u_dns
    
   pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers> port 5060 queue u_hipri

   pass out quick on $ext_if inet proto udp from ($ext_if) to any queue u_pri

   pass out quick on $ext_if inet proto icmp from ($ext_if) to any $mst queue u_lowpri

Есть один важный момент, на котором остановлюсь подробнее. Второе правило будет разрешать ТСР-соединения с роутера и в том числе на 80 порт. Под это правило так же подпадают пакеты, отправленные с прокси-сервера, трафик, который фактически является HTTP-трафиком  клиентов из локальной сети. Т.к. в нашем случае приоритеты этих видов трафика равны (очередь u_pri), то все хорошо. Но если планируется назначить очереди разные (например, HTTP от локальных клиентов - очередь u_lowpri, а с внешнего интерфейса роутера - u_pri), тогда следует указать в правиле для прокси-сервера опцию user uid и поместить его над правилом для внешнего интерфейса роутера. Например, прокси запущен с правами пользователя nobody:

   pass out quick on $ext_if inet proto tcp from ($ext_if) to any user nobody $mst queue (u_lowpri u_ack)

   pass out quick on $ext_if inet proto tcp from ($ext_if) to any $mst queue (u_pri u_ack)

Соответственно, правило, разрешающее доступ к прокси из локалной сети тоже немного измениться: необходимо поменять очередь с d_pri на d_lowpri.

   pass in log quick on $int_if inet proto tcp from ($int_if:network) to 127.0.0.1 port 31280 queue (d_lowpri, d_ack)

Стоить отметить о наличии бага, который проявляется при использованием опции user. Об этом описано в секции BUGS на странице руководства pf.conf. Лично у меня этот баг не проявлялся. Все же старайтесь опцию user не использовать.

Отладка. Отличительной способностью PF есть его протоколирование, статистика и мониторинг состояния в реальном времени что значительно облегчает конфигурирование файервола, особенно для сложных сетевых топологий.

Просмотр загруженных очередей:

   pfctl -sq

Что бы в реальном времени наблюдать загрузку очередей выполните команду:

   pfctl -vvsq

Так же рекомендую установить из портов программу pftop, которая по аналогии с утилитой top выводит различную статистику PF в реальном времени.

URL:
Обсуждается: https://www.opennet.ru/tips/info/2680.shtml

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от bga83 (ok) on 09-Апр-12, 14:27 
пропускная способность такого решения упрется в цифру 150-180 Мбит/сек. Больше pf просто не в состоянии обработать. Связано с тем, что он работает только в дин поток, в отличие от ipfw.

Касаемо непосредственно правил: наличие в правилах quick крайне нежелательно и можно отнести к ошибке автора, хотя с чисто формальной точки зрения все будет работать. К тому же есть подозрение, что не совсем корректно идет заворачивание трафика в очереди(надо более детально разбираться, но поверхностный анализ говорит именно об этом). По умолчанию все правила pf имеют keep state, а это значит, что обратные пакеты будут попадать под тоже самое правило и значит проходить те же очереди, что не является корректным.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 09-Апр-12, 18:47 
1. То что PF работает в один поток - не есть проблема до 800 Мбит/с на недорогих интеловых гигабитках. Можете прочесть хотя бы тут
https://calomel.org/network_performance.html
В репозитории имеется отдельный проект, основной задачей которого задействовать SMP для пакетного фильтра, так что недалек тот час ...
2. По правилам. Вы хоть одну статью читали по оптимизации PF?  Видимо нет. Из обязательных - PF: Firewall Ruleset Optimization написанная Даниэлем Хартмейером на OpenBSD Journal.
Так вот основная суть оптимизации - максимальный шаг пропуска (skip step). Опция quick в правиле срабатывает сразу по первому совпадению, а не происходит дальшейшее прохождение с целью поиска совпадений по рулесету.
По-поводу догадок о некорректности заворачивания. Такие конфги нормально работают на моих серверах давно и все нормально заворачивается. Поднимайте виртуалку и смотрите, а догадки оставьте при себе.

>По умолчанию все правила pf имеют keep state, а это значит, что обратные пакеты будут
>попадать под тоже самое правило и значит проходить те же очереди, что не является

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>корректным.

Это какая-то чушь, извините.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

24. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 03:11 
>  1. То что PF работает в один поток - не есть
> проблема до 800 Мбит/с на недорогих интеловых гигабитках. Можете прочесть хотя
> бы тут
> https://calomel.org/network_performance.html

можно пример "недорогой интеловской гигабитки"?
А то как бы 82576 стоит не так уж и недорого.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от mma on 10-Апр-12, 05:46 
>пропускная способность такого решения упрется в цифру 150-180 Мбит/сек

Ерунда, все упрется в железо(проц и сетевухи) а не в ядро и софт

>наличие в правилах quick крайне нежелательно и можно отнести к ошибке автора

Это почему?

>По умолчанию все правила pf имеют keep state, а это значит, что обратные пакеты будут попадать под тоже самое правило и значит проходить те же очереди, что не является корректным.

Все ведь зависит от политики: допустим statefull или только stateless

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

21. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Andrew Kolchoogin on 12-Апр-12, 00:51 
Нет, не будет проходить, и это FAQ.

ALTQ появляется в ядре путём патча сетевых драйверов -- макрос IF_DEQUEUE() заменяется на IFQ_DEQUEUE(). IFQ_ENQUEUE() не существует в природе -- ALTQ работает ТОЛЬКО с исходящими пакетами.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

5. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от unscrubber2 on 10-Апр-12, 07:29 
>Связано с тем, что он работает только
> в один поток, в отличие от ipfw.

возможно это проблема если адаптеров несколько (при нагруженном хостинге vds например, виртуализации)

> это, похоже, девиз FreeBSD

PF был портирован с OpenBSD, наезд не засчитан.
да и вообще, я использую и linux и freebsd, можно не придираться а просто использовать то что в определенных условиях и задачах лучше/удобней работает.
сборка мира сама по себе и коллекция портов стоят того чтобы познакомится/использовать freebsd.


! про SMP - скоро (с релизом 6 OpenBSD версии, щас бета есть) можно будет желающим использовать NPF (много общего вижу по возможностям и синтаксису с PF, смhttp://netbsd.gw.com/cgi-bin/man-cgi?npf.conf++NetBSD-current), https://www.opennet.ru/opennews/art.shtml?num=27955 , мне лично больше всего конечно интерпретатор байткода и прочие новшества нравятся.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 10-Апр-12, 09:41 
>[оверквотинг удален]
> да и вообще, я использую и linux и freebsd, можно не придираться
> а просто использовать то что в определенных условиях и задачах лучше/удобней
> работает.
> сборка мира сама по себе и коллекция портов стоят того чтобы познакомится/использовать
> freebsd.
> ! про SMP - скоро (с релизом 6 OpenBSD версии, щас бета
> есть) можно будет желающим использовать NPF (много общего вижу по возможностям
> и синтаксису с PF, смhttp://netbsd.gw.com/cgi-bin/man-cgi?npf.conf++NetBSD-current),
> https://www.opennet.ru/opennews/art.shtml?num=27955 , мне лично больше всего конечно
> интерпретатор байткода и прочие новшества нравятся.

  А вот это уже интересно. Я так понял планируется NPF портировать в Опенок? Так а сам то он в Нете уже работает?

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 10-Апр-12, 09:43 
>[оверквотинг удален]
>> сборка мира сама по себе и коллекция портов стоят того чтобы познакомится/использовать
>> freebsd.
>> ! про SMP - скоро (с релизом 6 OpenBSD версии, щас бета
>> есть) можно будет желающим использовать NPF (много общего вижу по возможностям
>> и синтаксису с PF, смhttp://netbsd.gw.com/cgi-bin/man-cgi?npf.conf++NetBSD-current),
>> https://www.opennet.ru/opennews/art.shtml?num=27955 , мне лично больше всего конечно
>> интерпретатор байткода и прочие новшества нравятся.
>   А вот это уже интересно. Я так понял планируется NPF
> портировать в Опенок? Так а сам то он в Нете уже
> работает?

))). У вас опечатка. Им имелось вввиду NetBSD.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от unscrubber2 on 10-Апр-12, 13:21 
да опечатался, по ссылкам же видно что о нетбсд речь)

оверквотинг удался)

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  –1 +/
Сообщение от Аноним (??) on 11-Апр-12, 01:40 
> Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c.

И вот для этого предлагается ставить здоровый гроб с бсдой? Да с этим тплинк 1000-рублевый справится. Который места занимает чисто символически, можно считать что ничего не жрет и у него не забьется пылью вентиль на проце или в бп.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 11-Апр-12, 03:28 
Сейчас есть множество решений на Intel Atom, что куда функциональней китайских поделок с встроенной ОС при сравнимом энергопотреблении и размерах.

По сути статьи - с какой-то версии OpenBSD для раскидывания по очередям удобнее вместо совмещения правил "pass" /"queue" использовать "match" / "queue", а правила "pass" использовать отдельно.

Кроме того - забыли про FTP трафик и прогу ftp-proxy, формируемый которой трафик следует загонять в 2 очереди (ACK и FTP), используя тегирование пакетов.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

12. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 11-Апр-12, 09:57 
> Сейчас есть множество решений на Intel Atom, что куда функциональней китайских поделок
> с встроенной ОС при сравнимом энергопотреблении и размерах.
> По сути статьи - с какой-то версии OpenBSD для раскидывания по очередям
> удобнее вместо совмещения правил "pass" /"queue" использовать "match" / "queue", а
> правила "pass" использовать отдельно.

Я использую FreeBSD 9, там  pf45 в нем еще не реализован упомянутый вами синтаксис. С OpenBSD есть одна проблема, а именно там невозможно по-моему ALTQ на интерфейсе моста (я не помню точно, но помню что в это я уперся однажды). Надо еще разобраться как там обстоят дела с другими "виртуальным" интерфейсами, например, vlan-ами.

> Кроме того - забыли про FTP трафик и прогу ftp-proxy, формируемый которой
> трафик следует загонять в 2 очереди (ACK и FTP), используя тегирование
> пакетов.

В статье я указал, что используется пассивный FTP. В таком случае эта прога не нужна. Если вам важен активный режим, тогда да, нужно использовать ftp-proxy.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

17. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko on 11-Апр-12, 16:49 
В пассивном тоже полезно, если открыты только определённые разрешённые порты. PF будет динамически открывать доступ к "левым" портам только для FTP DATA трафика.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

19. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 11-Апр-12, 18:15 
> В пассивном тоже полезно, если открыты только определённые разрешённые порты. PF будет
> динамически открывать доступ к "левым" портам только для FTP DATA трафика.

Может быть при "драконовской" конфигурации, когда открыто пол-десятка портов. Но при такой, как в этом куске конфига, данные будут попадать в INET_OTHER очередь. Впринципе жалоб, что не подключает по ФТП от пользователей не поступало :-).

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        $mst queue (d_other d_ack) tag INET_OTHER

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port {20 21 25 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port 443 $mst queue (d_pri d_ack) tag INET_PRI

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 11-Апр-12, 20:21 
> Может быть при "драконовской" конфигурации, когда открыто пол-десятка портов. Но при такой, как в этом куске конфига, данные будут попадать в INET_OTHER очередь.

Я на пятом опёнке раскидываю так:


ps ax | grep ftp
21897 ??  Is      0:00.04 /usr/sbin/ftp-proxy -T ftp-proxy

pfctl -sa | grep ftp-proxy
match on pppoe0 proto tcp all queue(def, pri) tagged ftp-proxy
anchor "ftp-proxy/*" all
pass in on pppoe0 inet proto tcp all flags S/SA tagged ftp-proxy

ACK пакеты попадают в приоритетную очередь.

Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

13. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 11-Апр-12, 14:14 
> Сейчас есть множество решений на Intel Atom

Только они куда крупнее и прожорливее и не конфигурируются на 100% ремотно как правило. Еще не хватало - мыши, клавы и дисплеи к роутерам цеплять.

> куда функциональней китайских поделок с встроенной ОС

В почти все таковые при желании льется openwrt, после чего вопрос функциональности отпадает. Оно умеет сразу дофига всего что нужно от роутера. В том числе и приоритеты. При том большинство типовых операций еще и делаются через удобную вебморду, хардкорить со скриптами приходится только в каких-то совсем нестандартных раскладах.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

18. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  –1 +/
Сообщение от Alexander Sheiko on 11-Апр-12, 16:56 
Да ну - 15-25 Вт максимум при 100% загрузке двухъядерного Атома. Клава и монитор нужны только для установки ОС.

Вебморда - это нечто домохозяйское :). Если мне захочется веб моруду - это будет pfSense .

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

80. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +1 +/
Сообщение от Аноним (??) on 14-Апр-12, 16:52 
> Да ну - 15-25 Вт максимум при 100% загрузке двухъядерного Атома.

А упомянутое спасибо если 5 ваттов в максимуме жрет, если в юсб понацеплять винчей/флех всяких и прчоая. А рассеять 25 ваттов без кулера в небольшом объеме уже крайне нетривиально. А кулер - заявка на то что он словит клин и будет нехорошо.

> Клава и монитор нужны только для установки ОС.

А в упомянутых штуках они вообше никогда не нужны.

> Вебморда - это нечто домохозяйское :).

Зато позволяет отконфигурить железку через 5 минут после покупки и/или силами тупого монтажника: вбить параметры в формочки может даже он. Без подключения к девайсу мониторов и клавиатур.

> Если мне захочется веб моруду - это будет pfSense .

А у меня получается меньше, экономнее, дешевле, современнее и ... решает поставленные задачи. Я на шаг впереди вас ;)

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

23. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +1 +/
Сообщение от ragus (ok) on 12-Апр-12, 03:09 
> Сейчас есть множество решений на Intel Atom, что куда функциональней китайских поделок
> с встроенной ОС при сравнимом энергопотреблении и размерах.

а не затруднит вас подтвердить ваши слова ссылками на предложения с ценниками и условиями доставки?

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

53. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 12-Апр-12, 22:47 
> а не затруднит вас подтвердить ваши слова ссылками на предложения с ценниками
> и условиями доставки?

Выбирайте:

http://hotline.ua/computer/materinskie-platy/7284-29309/

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

54. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 12-Апр-12, 22:58 
> http://hotline.ua/computer/materinskie-platy/7284-29309/

Разумеется - в формате mini-ITX. Вот такое, к примеру:

http://hotline.ua/computer-materinskie-platy/intel_d525mw/

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

81. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 14-Апр-12, 16:54 
> Разумеется - в формате mini-ITX. Вот такое, к примеру:

Вот незадача то: оно стоит как _три_ тплинка (являющихся законченной системой в сборе готовой к работе) которые разрулят все перечисленное на канале с указанной скорсотью ни разу не икнув.  И не является при этом готовой системой - надо еще корпус, БП, ... - обалденный "выигрыш".

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

56. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +1 +/
Сообщение от ragus (ok) on 12-Апр-12, 23:33 
>> а не затруднит вас подтвердить ваши слова ссылками на предложения с ценниками
>> и условиями доставки?
> Выбирайте:
> http://hotline.ua/computer/materinskie-platy/7284-29309/

по ссылке какие-то комплектующие для PC

1)блок питания?
2)корпус?
3)память
4)на чём-то ещё надо хранить ОС
5)там всего 1 ethernet, т.е. рядом ещё и коммутатор.

мой вариант: D-link DIR-620 + openwrt. не шумит, пассивное охлаждение, коммутатор на 4 порта с поддержкой vlan'ов. цена вопроса 57$

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

58. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 13-Апр-12, 00:47 
> по ссылке какие-то комплектующие для PC
> 1)блок питания?
> 2)корпус?
> 3)память

На любой выбор.

> 4)на чём-то ещё надо хранить ОС

Удобнее всего взять жёсткий диск - будет ещё бесплатное хранилище.

> 5)там всего 1 ethernet, т.е. рядом ещё и коммутатор.

Там два слота расширения.

> мой вариант: D-link DIR-620 + openwrt. не шумит, пассивное охлаждение, коммутатор на
> 4 порта с поддержкой vlan'ов. цена вопроса 57$

Тут тоже пассивное охлаждение, два ядра и огромный выбор под конкретные цели: кроме слотов расширения есть ещё USB. Для маршрутизатора сети - самое оно.

Что касается "гробов" - I815/512RAM/850Celeron/4fxp/20GbHDD жрёт всего 40 Вт и раздаёёт 100 Мбит интернет для ~270 ПК со всякими наворотами / правилами уже 12 лет, (для профилактики) меняли только БП. И запаса мощности хватит ещё на столько же ПК. Стоит это барахло не больше упомянутого D-link, но заткнёт его по любым параметрам, кроме размера и (смешного) энергопотребления. Всё это время на нём стояла FreeBSD 4 версии, недавно поставили девятку. Мало того, если заменить такой "гроб" таким D-link - сеть просто умрёт. Эта поделка годится для обслуживания всего пару-тройку ПК (до десятка).

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

59. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 01:09 
>> по ссылке какие-то комплектующие для PC
>> 1)блок питания?
>> 2)корпус?
>> 3)память
> На любой выбор.

вы ценник законенного решения назовите.

>> 4)на чём-то ещё надо хранить ОС
> Удобнее всего взять жёсткий диск - будет ещё бесплатное хранилище.

ценник растёт...

>> 5)там всего 1 ethernet, т.е. рядом ещё и коммутатор.
> Там два слота расширения.

я напоминаю про интегрированный 4портовый свитч с vlan'ми в железке за 57$

>> мой вариант: D-link DIR-620 + openwrt. не шумит, пассивное охлаждение, коммутатор на
>> 4 порта с поддержкой vlan'ов. цена вопроса 57$
> Тут тоже пассивное охлаждение, два ядра и огромный выбор под конкретные цели:
> кроме слотов расширения есть ещё USB. Для маршрутизатора сети - самое
> оно.

в DIR-620 есть порт USB2.0, в который можно воткнуть упомянутый вами hdd.
цена вопроса 57$ + цена hdd с коробочкой.

> Что касается "гробов" - I815/512RAM/850Celeron/4fxp/20GbHDD жрёт всего 40 Вт и раздаёёт
> 100 Мбит интернет для ~270 ПК со всякими наворотами / правилами
> уже 12 лет, (для профилактики) меняли только БП.

этому железу место в музее компьютерной истории.

>И запаса мощности
> хватит ещё на столько же ПК. Стоит это барахло не больше
> упомянутого D-link, но заткнёт его по любым параметрам, кроме размера и
> (смешного) энергопотребления.

ваше железо нуждается в обслуживании, в отличие от варианта "поставил и забыл".
у вашего варианта в случае любых приколов с питанием в лучшем случае будет долгий fsck.
врядли у вас система живёт на 1м винте, скорее всего gmirror. после проблем с электричеством велики шансы получить зеркало в degraded и его ребилд. к этому стоит добавить бегущий в это время fsck.

и да, я в курсе про background fsck, но если у вас в процессе снова исчезнет электричество, у вас будет полный fsck.

Всё это время на нём стояла FreeBSD 4 версии,
> недавно поставили девятку. Мало того, если заменить такой "гроб" таким D-link
> - сеть просто умрёт. Эта поделка годится для обслуживания всего пару-тройку
> ПК (до десятка).

всё зависит от целей и задач. у автора опуса не более 10 мбит. для этих целей упомянутого ранее длинка достаточно.
в вашем случае можно взять routerboard.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

61. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 13-Апр-12, 02:15 
> вы ценник законенного решения назовите.

Стоимость системника дешёвого офисного ПК "для секретутки".

> этому железу место в музее компьютерной истории.

Вот в этом и его плюс - поделка 12 летней давности для раздачи инета почти трём сотням машин оказалась куда практичней и функциональней современной мыльницы. Материнка там, кстати, - десктопный Интел. Интересно - D-Link физически проживёт 12 лет непрерывной эксплуатации :)? Свичи-мыльницы этого производителя столько не живут.

> ваше железо нуждается в обслуживании, в отличие от варианта "поставил и забыл".

Да - раз в год нужно пройтись пылесосом. Сложно, да?

> у вашего варианта в случае любых приколов с питанием

Железка питается через APC Smart UPS и имеет с ним взаимовыгодные сношения.

> врядли у вас система живёт на 1м винте

Древняя барракуда на 20 гиг. Есть его зеркало на таком же винте - лежит в ящике, на случай вылета основного. Годовая разница будет лишь в паре конфигов.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

68. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 15:27 
>> вы ценник законенного решения назовите.
> Стоимость системника дешёвого офисного ПК "для секретутки".

т.е. 200$ где-то. за эти деньги можно взять routerboard с 5-6 гигабитными интерфейсами и wifi на борту с корпусом и блоком питания. без движущихся частей и пассивным охлаждением.

>Интересно - D-Link
> физически проживёт 12 лет непрерывной эксплуатации :)? Свичи-мыльницы этого производителя
> столько не живут.

надеюсь, ваши слова на чём-то основаны и вам есть чем подтвердить ваши слова?

>> ваше железо нуждается в обслуживании, в отличие от варианта "поставил и забыл".
> Да - раз в год нужно пройтись пылесосом. Сложно, да?

пылесос? в офисе? кто вообще это делать будет? уборщица? если у вас один офис и вы туда регулярно ходите - да, можете хоть каждый день пыль тряпочкой вытирать. когда у вас несколько десятков офисов по рф - это дорого.

>> у вашего варианта в случае любых приколов с питанием
> Железка питается через APC Smart UPS и имеет с ним взаимовыгодные сношения.

аккумулляторы в UPS имеют свойство разряжаться. там, где отключают электричество часто упсы долго не живут и нуждаются в замене аккумулляторов часто.

>> врядли у вас система живёт на 1м винте
> Древняя барракуда на 20 гиг. Есть его зеркало на таком же винте
> - лежит в ящике, на случай вылета основного. Годовая разница будет
> лишь в паре конфигов.

тогда проще систему в r/o и на usb-флеш. дальнейшее развитие варианта - это как раз коробочка с dlink + openwrt + внешний винт.

Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

71. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 19:01 
>>> вы ценник законенного решения назовите.
>> Стоимость системника дешёвого офисного ПК "для секретутки".
> т.е. 200$ где-то. за эти деньги можно взять routerboard с 5-6 гигабитными
> интерфейсами и wifi на борту с корпусом и блоком питания. без
> движущихся частей и пассивным охлаждением.

не те задачи, что бы роутермамку брать.

>>Интересно - D-Link
>> физически проживёт 12 лет непрерывной эксплуатации :)? Свичи-мыльницы этого производителя
>> столько не живут.
> надеюсь, ваши слова на чём-то основаны и вам есть чем подтвердить ваши
> слова?

Опыт, уважаемый, опыт ))

>>> ваше железо нуждается в обслуживании, в отличие от варианта "поставил и забыл".
>> Да - раз в год нужно пройтись пылесосом. Сложно, да?
> пылесос? в офисе? кто вообще это делать будет? уборщица? если у вас
> один офис и вы туда регулярно ходите - да, можете хоть
> каждый день пыль тряпочкой вытирать. когда у вас несколько десятков офисов
> по рф - это дорого.

Ага, и вы раскажите про себя единого, работающего по удаленке, а на месте даже приходящего админа нет. Бред. видел я такую модель работы, опять таки фирмочка из рф. У вас, чче так принято? ))

>>> у вашего варианта в случае любых приколов с питанием
>> Железка питается через APC Smart UPS и имеет с ним взаимовыгодные сношения.
> аккумулляторы в UPS имеют свойство разряжаться. там, где отключают электричество часто
> упсы долго не живут и нуждаются в замене аккумулляторов часто.

И что?
А еще винты иногда сыпяться, порты на свичях горят и т.д. и т.п.


>>> врядли у вас система живёт на 1м винте
>> Древняя барракуда на 20 гиг. Есть его зеркало на таком же винте
>> - лежит в ящике, на случай вылета основного. Годовая разница будет
>> лишь в паре конфигов.
> тогда проще систему в r/o и на usb-флеш. дальнейшее развитие варианта -
> это как раз коробочка с dlink + openwrt + внешний винт.

Да, верно. так и делаем. А зачем тратиться на глючный длинк, если можно взять имеющийся десктопный ПК и организовать на нем роутер. И, да вы пытаетесь сравнить х. с  п. (имеется ввиду *BSD vs openwrt.)

и, последнее, терпение уж точно закончилось читать ваши посты, походу мой - это последний. так что задавайте вопросы со своими ответами :-)


Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

74. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 20:07 
> Ага, и вы раскажите про себя единого, работающего по удаленке, а на
> месте даже приходящего админа нет. Бред. видел я такую модель работы,
> опять таки фирмочка из рф. У вас, чче так принято? ))

да, всего два админа. за счёт экономии на количестве админов зарплаты выше.

> И что?
> А еще винты иногда сыпяться, порты на свичях горят и т.д. и
> т.п.

я же говорю: ещё одна такая же коробка на полке и вопрос закрыт.
с перетыканием проводов справится даже девочка(если только она не дальтоник - патчкорды цветные, хотя и тут могут быть варианты).
А переставить hdd/поставить новый hdd - это куда сложнее.

> Да, верно. так и делаем. А зачем тратиться на глючный длинк, если
> можно взять имеющийся десктопный ПК и организовать на нем роутер. И,
> да вы пытаетесь сравнить х. с  п. (имеется ввиду *BSD
> vs openwrt.)

ну так в чём глючность то? на длинковских железках построено много разных сетей, его не гнушаются и крупные операторы, ориентированные на бизнес.

у soho-железок длинка одна беда - это прошивка, которая решается с помощью openwrt.

ваш вариант:

1)дороже
2)требует периодического обслуживания
3)в случае описываемого вами adsl рядом всё равно есть аналогичная коробочка от dlink/asus/planet/tp-link/etc.

в чём профит то?

> и, последнее, терпение уж точно закончилось читать ваши посты, походу мой -
> это последний. так что задавайте вопросы со своими ответами :-)

главное - вовремя убежать :)

Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

76. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 21:14 

> главное - вовремя убежать :)

Я ценю свое время и не хочу его тратить на прочтение ваших бредней. Ну без обид. ок?

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

107. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от alex.h (??) on 22-Апр-12, 15:11 
> у soho-железок длинка одна беда - это прошивка, которая решается с помощью openwrt.

Ради правды, у указанного класса железок две беды, вторая БП - который сначала греется, потом - умирает. Впрочем, раньше и сами железки грелись.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

77. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko on 13-Апр-12, 21:18 
>>Интересно - D-Link физически проживёт 12 лет непрерывной эксплуатации :)? Свичи-мыльницы этого производителя столько не живут.
> надеюсь, ваши слова на чём-то основаны и вам есть чем подтвердить ваши
> слова?

Да - десятком таких коробок в ящике, ждущих свою очередь на списание. Живут до 2-3 лет. Модели в металлическом корпусе куда более живучие.

> пылесос? в офисе? кто вообще это делать будет?

Штатный сисадмин. Раз в год потратит час времени. Ужасно трудоёмко, да.

> аккумулляторы в UPS имеют свойство разряжаться. там, где отключают электричество часто
> упсы долго не живут и нуждаются в замене аккумулляторов часто.

Видимо, Вы себе не представляете, что такое APC Smart UPS при малой нагрузке (14%). Батареям уже 8 лет, емкость держат. Свет пропадает раз в неделю - две. Батареи ниже 75 ёмкости не сажаю, 25% - это 15 минут. На нём два таких сервера, два свича, три оптоконвертера.

artemrts> терпение уж точно закончилось читать ваши посты, походу мой - это последний. так что задавайте вопросы со своими ответами :-)

+1 - мне надоело тоже.

Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

78. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 23:24 
>>>Интересно - D-Link физически проживёт 12 лет непрерывной эксплуатации :)? Свичи-мыльницы этого производителя столько не живут.
>> надеюсь, ваши слова на чём-то основаны и вам есть чем подтвердить ваши
>> слова?
> Да - десятком таких коробок в ящике, ждущих свою очередь на списание.
> Живут до 2-3 лет. Модели в металлическом корпусе куда более живучие.

модель какая?

>> пылесос? в офисе? кто вообще это делать будет?
> Штатный сисадмин. Раз в год потратит час времени. Ужасно трудоёмко, да.

ок, я уточню ситуацию. компания занимается логистикой. офисы - это помещения площадью в 120-160 кв. м. расположенные чаще всего в промзонах городов. на момент моей работы в той компании было 43 города рф. для каждого такого "офиса" держать штатного сисадмина?

другой пример: офисы продаж какого-нибудь МТС(которые, на самом деле принадлежат ЗАО "РТК"). их по городу сотни.  

> Видимо, Вы себе не представляете, что такое APC Smart UPS при малой
> нагрузке (14%). Батареям уже 8 лет, емкость держат. Свет пропадает раз
> в неделю - две. Батареи ниже 75 ёмкости не сажаю, 25%
> - это 15 минут. На нём два таких сервера, два свича,
> три оптоконвертера.

ключевое слово - промзона. включили где-то рядом сварочник/сработала защита от КЗ => итп.
и в случае двух серверов как вы узнаете, что сосед себя корректно погасил?

Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

60. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 01:42 
>> по ссылке какие-то комплектующие для PC
>> 1)блок питания?
>> 2)корпус?
>> 3)память
> На любой выбор.

да, ещё у dir-620 на борту 802.11n wifi адаптер.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

63. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 07:43 
>>> по ссылке какие-то комплектующие для PC
>>> 1)блок питания?
>>> 2)корпус?
>>> 3)память
>> На любой выбор.
> да, ещё у dir-620 на борту 802.11n wifi адаптер.

Это когда роутер у бухгалтера под тумбочкой :-). Лично у меня он в серверной и этот адаптер ни к чему. Так что не лепите домашний роутер в корпоративный сегмент.

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

66. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 14:16 
>>>> по ссылке какие-то комплектующие для PC
>>>> 1)блок питания?
>>>> 2)корпус?
>>>> 3)память
>>> На любой выбор.
>> да, ещё у dir-620 на борту 802.11n wifi адаптер.
> Это когда роутер у бухгалтера под тумбочкой :-). Лично у меня он
> в серверной и этот адаптер ни к чему. Так что не
> лепите домашний роутер в корпоративный сегмент.

и что, по всему офису только провода? и чем плох этот роутер в "корпоративном сегменте"?
на нём, кстати, можно делать статические L2-туннели

ок, вы сами сказали про корпоратив. чуть ранее мы обсуждали платы с intel atom. А как вы mATX в 1U корпус запихнёте?

и как вы идентифицируете пользователей? только по ip? никаких 802.1x и ацесс-листов на прокси по группам в Active Directory?
ваша схема шейпинга держится на доверии к определённым пользователям, что тоже плохо.

пока всё что вы описали вполне заменяется коробкой за 50-60$
тем более, что в случае с adsl где-то сбоку есть такая же коробка в виде adsl-модема.
а когда офисов не один, а штук 30-40 и там только девушки-менеджеры и операционистки, то необслуживаемые решения рулят и педалят.

Ответить | Правка | ^ к родителю #63 | Наверх | Cообщить модератору

69. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 18:46 
>[оверквотинг удален]
>>>>> 1)блок питания?
>>>>> 2)корпус?
>>>>> 3)память
>>>> На любой выбор.
>>> да, ещё у dir-620 на борту 802.11n wifi адаптер.
>> Это когда роутер у бухгалтера под тумбочкой :-). Лично у меня он
>> в серверной и этот адаптер ни к чему. Так что не
>> лепите домашний роутер в корпоративный сегмент.
> и что, по всему офису только провода? и чем плох этот роутер
> в "корпоративном сегменте"?

Причем тут провода, там где роутеру место от туда сигнала хватает до первого угла коридора. А если от проводов отказіваюсь, то в пользу таких продуктов как Ubiquiti UniFi. Слышали о таких. А смесь булдога с носорогом в представленной вами железки меня не устраивает в 90% случаев.

> на нём, кстати, можно делать статические L2-туннели
> ок, вы сами сказали про корпоратив. чуть ранее мы обсуждали платы с
> intel atom. А как вы mATX в 1U корпус запихнёте?

повашему корпоратив - это исключительно рекмаунт?

> и как вы идентифицируете пользователей? только по ip? никаких 802.1x и ацесс-листов
> на прокси по группам в Active Directory?
> ваша схема шейпинга держится на доверии к определённым пользователям, что тоже плохо.

В каждом отдельнов варианте по-разному. В описанном мной такого не потребовалось.

> пока всё что вы описали вполне заменяется коробкой за 50-60$
> тем более, что в случае с adsl где-то сбоку есть такая же
> коробка в виде adsl-модема.
> а когда офисов не один, а штук 30-40 и там только девушки-менеджеры
> и операционистки, то необслуживаемые решения рулят и педалят.

В такой компании при таком кол-ве офисов всякие домороутеры с левой начинкой абсолютно не приемлемо. Де вы такое видели?

Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

72. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 19:11 
> Причем тут провода, там где роутеру место от туда сигнала хватает до
> первого угла коридора. А если от проводов отказіваюсь, то в пользу
> таких продуктов как Ubiquiti UniFi. Слышали о таких.

ну приносили нам их на тесты. 4VAP'а сейчас умеют почти все более-менее приличные wifi-чипы. даже zyd умеет. в чём цимес то, кроме бесплатного контроллера?
afaik, внутри Ubiquiti UniFi слегка допиленный *wrt.


>> intel atom. А как вы mATX в 1U корпус запихнёте?
> повашему корпоратив - это исключительно рекмаунт?

т.е. всё-таки "сервер под столом бухгалтера/админа"?

>> пока всё что вы описали вполне заменяется коробкой за 50-60$
>> тем более, что в случае с adsl где-то сбоку есть такая же
>> коробка в виде adsl-модема.
>> а когда офисов не один, а штук 30-40 и там только девушки-менеджеры
>> и операционистки, то необслуживаемые решения рулят и педалят.
> В такой компании при таком кол-ве офисов всякие домороутеры с левой начинкой
> абсолютно не приемлемо. Де вы такое видели?

делал. работает и не убивается. резерв держать совсем дёшево. время перехода на резерв - это переткнуть кабели и дождаться загрузки. по силам даже тётенькам 55-60лет.

Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

75. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 21:09 
>[оверквотинг удален]
>>> пока всё что вы описали вполне заменяется коробкой за 50-60$
>>> тем более, что в случае с adsl где-то сбоку есть такая же
>>> коробка в виде adsl-модема.
>>> а когда офисов не один, а штук 30-40 и там только девушки-менеджеры
>>> и операционистки, то необслуживаемые решения рулят и педалят.
>> В такой компании при таком кол-ве офисов всякие домороутеры с левой начинкой
>> абсолютно не приемлемо. Де вы такое видели?
> делал. работает и не убивается. резерв держать совсем дёшево. время перехода на
> резерв - это переткнуть кабели и дождаться загрузки. по силам даже
> тётенькам 55-60лет.

Сказки и чепуха. Так суппорт удаленных филиадов не делают.

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

79. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 23:27 
>[оверквотинг удален]
>>>> тем более, что в случае с adsl где-то сбоку есть такая же
>>>> коробка в виде adsl-модема.
>>>> а когда офисов не один, а штук 30-40 и там только девушки-менеджеры
>>>> и операционистки, то необслуживаемые решения рулят и педалят.
>>> В такой компании при таком кол-ве офисов всякие домороутеры с левой начинкой
>>> абсолютно не приемлемо. Де вы такое видели?
>> делал. работает и не убивается. резерв держать совсем дёшево. время перехода на
>> резерв - это переткнуть кабели и дождаться загрузки. по силам даже
>> тётенькам 55-60лет.
> Сказки и чепуха. Так суппорт удаленных филиадов не делают.

да чёрт с ним с саппортом. лучше ответьте на мой вопрос про приоритезацию голоса. это куда интереснее. может, я и правда чего-то важное упустил :)

Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

82. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 14-Апр-12, 17:22 
> На любой выбор.

Денег опять же стоят.

>> 4)на чём-то ещё надо хранить ОС
> Удобнее всего взять жёсткий диск - будет ещё бесплатное хранилище.

Во первых, диск можно и к роутеру прицепить если много не надо. А если надо много - так адом с бсдой тоже чемпионские результаты не покажет. Во вторых, это надо не всем и платить за диск если он не требовался - достаточно странно.

>> 5)там всего 1 ethernet, т.е. рядом ещё и коммутатор.
> Там два слота расширения.

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

>> мой вариант: D-link DIR-620 + openwrt. не шумит, пассивное охлаждение, коммутатор на
>> 4 порта с поддержкой vlan'ов. цена вопроса 57$
> Тут тоже пассивное охлаждение,

При 25W? Ну-ну. Это потребуется или гигантская корпусяка размером с вагон тех длинков или оно пожарится при случае. Или вентиль, как ни крути. Рассеять 25W в малых габаритах без перегрева - нереально.

> два ядра и огромный выбор под конкретные цели: кроме слотов расширения есть ещё USB.

У всяких длинков и тплинков как ни странно usb тоже есть. В том числе у экспонатов за 1000 рублей.

> Для маршрутизатора сети - самое оно.
> Что касается "гробов" - I815/512RAM/850Celeron/4fxp/20GbHDD жрёт всего 40 Вт

Эталонный такой гроб, в котором один только винч жрет как весь мелкий роутер.

> и раздаёёт 100 Мбит интернет

100Мбит раздаст и мелкая мыльница.

> для ~270 ПК со всякими наворотами / правилами уже 12 лет,
> (для профилактики) меняли только БП.

Ага, а также чистили вентиляторы, етц, етц. Не говоря о том что на половине мам за 12 лет кондеры просто напросто пухнут.

> И запаса мощности хватит ещё на столько же ПК. Стоит это барахло не больше
> упомянутого D-link, но заткнёт его по любым параметрам, кроме размера и
> (смешного) энергопотребления.

А также надежности, ибо железка только с фабрики vs железка 12-летней давности с вентилятрами... тем более что вентиляторы в пыльных местах любят ловить клинч намотав пыли.

> - сеть просто умрёт. Эта поделка годится для обслуживания всего пару-тройку
> ПК (до десятка).

Все в RAM упирается, если коннтрек нужен. Только вот разыскивать по помойкам древний 12-летний хлам - очень на любителя.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

11. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 11-Апр-12, 09:48 
>> Скорость от провайдера - 5 Мбит/c, к провайдеру - 850 Кбит/c.
> И вот для этого предлагается ставить здоровый гроб с бсдой? Да с
> этим тплинк 1000-рублевый справится. Который места занимает чисто символически, можно
> считать что ничего не жрет и у него не забьется пылью
> вентиль на проце или в бп.

Дело в том, что такой "гроб" имеет больше возможностей. Например, на этом сервере запущен Астериск. Например, у другого клиента при похожей конфигурации PF, существуют удаленные подсети по IPSec. Потребуется клиенту еще какая-нибудь функциональность - без проблем. А что вы с вашим тплинком сделаете?

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

14. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 11-Апр-12, 14:22 
> Дело в том, что такой "гроб" имеет больше возможностей.

Да ничего он не имеет. В каждую первую железку за тыщщу льется тот же опенврт и дальше - ну вы поняли.

> Например, на этом сервере запущен Астериск.

Этого для начала не было указано нигде. Впрочем астериск можно и на опенврт поставить. На тысячерублевую железку, да.

> А что вы с вашим тплинком сделаете?

Залью openwrt, далее то же самое что и вы, только 95% типовых задач роутера там уже разрюханы удобной аяксной вебмордой к тому же, где только параметры вписать и готово. А если чего-то нет то в конечном итоге это обычный пингвин. Даже пакеты можно доустановить.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от iZEN (ok) on 11-Апр-12, 15:20 
>> Дело в том, что такой "гроб" имеет больше возможностей.
> Да ничего он не имеет. В каждую первую железку за тыщщу льется
> тот же опенврт и дальше - ну вы поняли.

Что за бред?! Железки за тыщу рублей умеют максимум 70 kpps. А этот "гроб" переваривает за 1000 kpps.

>> Например, на этом сервере запущен Астериск.
> Этого для начала не было указано нигде. Впрочем астериск можно и на
> опенврт поставить. На тысячерублевую железку, да.

Поставьте, а мы поглядим, как вы свяжете цифровой телефонией десяток клиентов хомероутером. :))

>> А что вы с вашим тплинком сделаете?
> Залью openwrt, далее то же самое что и вы, только 95% типовых
> задач роутера там уже разрюханы удобной аяксной вебмордой к тому же,
> где только параметры вписать и готово. А если чего-то нет то
> в конечном итоге это обычный пингвин.

Ну а здесь PF — писать внятные правила на порядок удобнее и красивее, чем в этом вашем IPTABLES — это как Pascal и Assembler.

> Даже пакеты можно доустановить.

Вот достижение! А на FreeBSD можно не только доустановить, но и собрать ПО с нужными опциями ШТАТНО. Сюрприз?

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

22. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +1 +/
Сообщение от ragus (ok) on 12-Апр-12, 03:07 
> Что за бред?! Железки за тыщу рублей умеют максимум 70 kpps. А
> этот "гроб" переваривает за 1000 kpps.

Изя, вы как всегда мимо кассы.

1)для 1mpps надо гигабитный порт.
2)для 100 мбит предел - 144 kpps
3)у автора - 5+1 Мбит.
4)144kpps на intel atom не прожевать даже на чистом роутинге

> Поставьте, а мы поглядим, как вы свяжете цифровой телефонией десяток клиентов хомероутером.
> :))

слышал звон, да не знаешь где он. расскажи про наличие драйверов под PRI-карточки на openbsd/freebsd. Кроникс? - нет, спасибо. Дигиум - ну более-менее терпимо, да.
Из опробованных мной и более всего понравившихся - Сангома.

> Ну а здесь PF — писать внятные правила на порядок удобнее и
> красивее, чем в этом вашем IPTABLES — это как Pascal и
> Assembler.

вот только:
1)возможностей у iptables больше
2)не нуждается в костылях для трансляции "сложных" протоколов.
3)для netfilter есть модули аппаратной акселерации nat для роутерных SoC

> Вот достижение! А на FreeBSD можно не только доустановить, но и собрать
> ПО с нужными опциями ШТАТНО. Сюрприз?

расскажи про процесс пересборки мира и ядра на intel atom или arm/mips

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

26. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от iZEN (ok) on 12-Апр-12, 07:41 
>> Что за бред?! Железки за тыщу рублей умеют максимум 70 kpps. А
>> этот "гроб" переваривает за 1000 kpps.
> Изя, вы как всегда мимо кассы.

За "Изю" когда-нибудь ты ответишь.

> 1)для 1mpps надо гигабитный порт.

А здесь что?!

> 2)для 100 мбит предел - 144 kpps

Вот именно. За 1000 рублей не купишь гигабитку.

> 3)у автора - 5+1 Мбит.

И?

> 4)144kpps на intel atom не прожевать даже на чистом роутинге

И?

[без комментариев]

>> Ну а здесь PF — писать внятные правила на порядок удобнее и
>> красивее, чем в этом вашем IPTABLES — это как Pascal и
>> Assembler.
> вот только:
> 1)возможностей у iptables больше

Не надо больше. Надо удобнее и легко поддерживаемо.

> 2)не нуждается в костылях для трансляции "сложных" протоколов.

Сложные протоколы на то и сложные (составные), что нуждаются по жизни в костылях в виде внешних по отношению к роутеру программ. Они требуют внимания сами по себе, а уж что там наворотить в правилах IPTABLES для них — сам ноги сломаешь. Пусть лучше котлеты отдельно, мухи отдельно.

> 3)для netfilter есть модули аппаратной акселерации nat для роутерных SoC

У автора "гроб".

>> Вот достижение! А на FreeBSD можно не только доустановить, но и собрать
>> ПО с нужными опциями ШТАТНО. Сюрприз?
> расскажи про процесс пересборки мира и ядра на intel atom или arm/mips

А что, Atom уже не процессор и компилировать не умеет. [arm] поддерживается на экспериментальном уровне. Можно использовать штатно кросс-компиляцию системы и ПО для архитектуры [arm].

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

27. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 08:45 
>> 1)для 1mpps надо гигабитный порт.
>А здесь что?!

зачем 1GE порты при трафике до 100мбит? автор писал про медленные adsl-линки.

>> 2)для 100 мбит предел - 144 kpps
>Вот именно. За 1000 рублей не купишь гигабитку.

1650 руб. не гигабит, но задачи автора покроет. на борту RT3050+32Mb RAM + USB2.0

http://market.yandex.ru/model.xml?modelid=6839062&hid=723087

>> 3)у автора - 5+1 Мбит.
>И?

зачем ему гигабит?

>> 4)144kpps на intel atom не прожевать даже на чистом роутинге
>И?

тогда к чему был пассаж про intel atom и 1mpps?

>[без комментариев]

очень жаль. значит, про драйвера для PRI-карточек мы ничего не услышим =((
вот так всегда с одептами *BSD.

>Не надо больше. Надо удобнее и легко поддерживаемо.

какая милая мантра от одептов PF.
такая простая вещь, как отправка "долгоиграющих" соединений им недоступна(для тех кто не понял зачем: чтобы торренты/закачки не мешали всему остальному трафику, т.е. после того как через соединение пробежало более N сотент килобайт мы снижаем приоритет этого трафика).

>Сложные протоколы на то и сложные (составные), что нуждаются по жизни в костылях в виде внешних по отношению к роутеру программ.

да-да. повторяйте это чаще. только вот libalias во freebsd вполне успешно умеет с ними работать, как и netfilter.

>А что, Atom уже не процессор и компилировать не умеет.

время - деньги.
кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный + in order архитектуру atom'а интел лечит костыликом hyper-threading.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

28. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 09:40 

> время - деньги.
> кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный
> + in order архитектуру atom'а интел лечит костыликом hyper-threading.

Да вы про src.conf ничего не слышали? Для сервера многое из базовой системы не нужно. Я даже на старом Слероне ядро и мир за 1,5 часа пересобираю в tmux'е, а вы тут про время-деньги раскричались)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

31. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 09:57 
>> время - деньги.
>> кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный
>> + in order архитектуру atom'а интел лечит костыликом hyper-threading.
> Да вы про src.conf ничего не слышали?

слышал и использую. и что?

> Я даже на старом Слероне ядро и мир
> за 1,5 часа пересобираю в tmux'е, а вы тут про время-деньги
> раскричались)

атому до вашего целерона как до луны пешком.
а про время-деньги: с точки зрения организации где вы работаете деньги, заплачены за эти 1.5 часа зря.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

36. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 13:08 
>[оверквотинг удален]
>>> кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный
>>> + in order архитектуру atom'а интел лечит костыликом hyper-threading.
>> Да вы про src.conf ничего не слышали?
> слышал и использую. и что?
>> Я даже на старом Слероне ядро и мир
>> за 1,5 часа пересобираю в tmux'е, а вы тут про время-деньги
>> раскричались)
> атому до вашего целерона как до луны пешком.
> а про время-деньги: с точки зрения организации где вы работаете деньги, заплачены
> за эти 1.5 часа зря.

Молодой человек. Эти полтора часа не проведенные за консолью. Запустилось себе в 3 часа ночи, я в свободное время обновил систему и все ок!
О каком время-деньги вы говорите? :-)

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

42. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 13:27 
> Молодой человек. Эти полтора часа не проведенные за консолью. Запустилось себе в
> 3 часа ночи, я в свободное время обновил систему и все
> ок!
> О каком время-деньги вы говорите? :-)

вы ночью просто так работаете? а где тесты, обкатка итп?

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

62. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Alexander Sheiko email on 13-Апр-12, 02:26 
> атому до вашего целерона как до луны пешком.

У меня есть нетбук на 455 атоме, он работает прилично быстрее МОЕГО целерона (см. выше - я на таком на работе ещё сижу, мощнее не нужно). Думаю - дальнейшая мысль понятна...

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

65. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 07:58 
>>> время - деньги.
>>> кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный
>>> + in order архитектуру atom'а интел лечит костыликом hyper-threading.
>> Да вы про src.conf ничего не слышали?
> слышал и использую. и что?
>> Я даже на старом Слероне ядро и мир
>> за 1,5 часа пересобираю в tmux'е, а вы тут про время-деньги
>> раскричались)
> атому до вашего целерона как до луны пешком.

lol. Я о том, который  Willamette :-)

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

30. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 09:46 

> время - деньги.
> кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный
> + in order архитектуру atom'а интел лечит костыликом hyper-threading.

У вас какое-то странное представление об однопоточности pf. Однопоточный - не значит тормозной. В реальном мире я не тестировал на производитеоьность, только на виртуалке. У меня тестовая машина AMD Phenom II X4, Виртуалбоксу отдано 2 ядра, 512МБ ОЗУ. 100Мбит в нате при таком наборе правил - загрузка процессора 80%. И это без тюнинга.
Реальное тестирование можете посмотреть на https://calomel.org/network_performance.html

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

33. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 10:02 
>> время - деньги.
>> кстати, насчёт атома: на нём pf - особенный тормоз будет, т.к. однопоточный
>> + in order архитектуру atom'а интел лечит костыликом hyper-threading.
> У вас какое-то странное представление об однопоточности pf. Однопоточный - не значит
> тормозной.

спасибо, кэп! dummynet вполне себе однопоточный и на него не жалуются.

> В реальном мире я не тестировал на производитеоьность,

может, с этого и стоило начать? :)

> 100Мбит в нате при таком наборе правил
> - загрузка процессора 80%. И это без тюнинга.

1)какое отношение мегабиты имеют к производительности пакетного фильтра?
2)то что вы показали - это очень много в плане cpu usage
3)что вы собираетесь тюнить?

> Реальное тестирование можете посмотреть на https://calomel.org/network_performance.html

по существу оттуда:

1)использовать freebsd
2)не использовать pf

Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

100. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 16-Апр-12, 20:49 
> За "Изю" когда-нибудь ты ответишь.

А ты когда-нибудь ответишь за свои килобайты ламерского бреда. Это хуже. Поэтому давай ты будешь разевать рот только если хоть немного разбираешься в вопросе.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

51. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 12-Апр-12, 16:23 
> вот только:
>1)возможностей у iptables больше

Бред. даже коментировать лениво.

> 2)не нуждается в костылях для трансляции "сложных" протоколов.

это connection tracking не костыль ?! с его линейным поиском конекта к которому относится данный пакет ?!

> 3)для netfilter есть модули аппаратной акселерации nat для роутерных SoC

Апаратный NAT это да.. это 10 даже а не 5. пиши бред дальше - хочется посметься.

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

57. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 23:40 
>> вот только:
>>1)возможностей у iptables больше
> Бред. даже коментировать лениво.

когда сказать нечего - лучше молчать.

>> 2)не нуждается в костылях для трансляции "сложных" протоколов.
> это connection tracking не костыль ?! с его линейным поиском конекта к
> которому относится данный пакет ?!

анонимные эксперты на марше. в conntrack хэш-таблица и поиск в ней O(1)

>> 3)для netfilter есть модули аппаратной акселерации nat для роутерных SoC
> Апаратный NAT это да.. это 10 даже а не 5. пиши бред
> дальше - хочется посметься.

смейтесь дальше: http://www.ralinktech.com/en/02_products/product.php?sn=1040
раздел features.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

108. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от alex.h (??) on 22-Апр-12, 15:56 
Вроде бы тут раньше уже как-то обсуждали аппаратную акселерацию NAT, получалось что проц разгружается, но возможностей по обработке пакетов и поддержке протоколов (вроде ppoe/pptp) становится меньше. При таком раскладе не однозначный плюс получается, т.е. где-то плюс, а где-то - не очень.
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

83. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 14-Апр-12, 17:36 
> Что за бред?! Железки за тыщу рублей умеют максимум 70 kpps.

Да вообще-то и больше умеют - 400МГц проц переварит и поболее, имхо. Как раз под потолок для 100Мбит роутинга.

> А этот "гроб" переваривает за 1000 kpps.

На атоме? 1000kpps? А продемонстрируешь на бис? Особенно как оно потом в 5мбитов :) :) утрамбуется. Грубый прикидон показывает что при 1000kpps и 5 мбит на 1 пакет получится никак не более 5 битов. Тебе не кажется что тут какие-то нестыковки? :)

> Поставьте, а мы поглядим, как вы свяжете цифровой телефонией десяток клиентов
> хомероутером. :))

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

>> Залью openwrt [..] в конечном итоге это обычный пингвин.
> Ну а здесь PF — писать внятные правила на порядок удобнее и
> красивее, чем в этом вашем IPTABLES — это как Pascal и Assembler.

Да, я видел, особенно удавка пакета по совпадению данных по некоему смещению - вот там у вас натурально BPFовский ассемблер начинается. А у айпитаблеса тупо модуль такой есть :)

>> Даже пакеты можно доустановить.
> Вот достижение! А на FreeBSD можно не только доустановить, но и собрать
> ПО с нужными опциями ШТАТНО. Сюрприз?

Ты еще предложи на роутере пакеты собирать.

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

85. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +1 +/
Сообщение от iZEN (ok) on 14-Апр-12, 22:12 
>> Что за бред?! Железки за тыщу рублей умеют максимум 70 kpps.
> Да вообще-то и больше умеют - 400МГц проц переварит и поболее, имхо.
> Как раз под потолок для 100Мбит роутинга.
>> А этот "гроб" переваривает за 1000 kpps.
> На атоме?

Кто сказал "атом"? В моём лексиконе такого слова нет. Берём обычный 35-45 ваттный AMD Athlon 64 X2 3800+, вставляем в материнку в Socket AM2. В PCI-E вставляем взрослый сетевой адаптер...

> 1000kpps? А продемонстрируешь на бис? Особенно как оно потом в
> 5мбитов :) :) утрамбуется. Грубый прикидон показывает что при 1000kpps и
> 5 мбит на 1 пакет получится никак не более 5 битов.
> Тебе не кажется что тут какие-то нестыковки? :)

Мне кажется, ты не совсем точно понимаешь функции пакетного фильтра. Скажу по секрету: для пакетного фильтра не важен размер содержимого пакета, PF работает с заголовками. ;)

>> Поставьте, а мы поглядим, как вы свяжете цифровой телефонией десяток клиентов
>> хомероутером. :))
> Да в общем то работает. Насчет десятка правда хз, но вообще -
> пашет. Однако в исходной задаче вообще про это не говорится.

Адью.

Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

86. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  –1 +/
Сообщение от ragus (ok) on 15-Апр-12, 02:57 
>>> Что за бред?! Железки за тыщу рублей умеют максимум 70 kpps.
>> Да вообще-то и больше умеют - 400МГц проц переварит и поболее, имхо.
>> Как раз под потолок для 100Мбит роутинга.
>>> А этот "гроб" переваривает за 1000 kpps.
>> На атоме?
> Кто сказал "атом"? В моём лексиконе такого слова нет. Берём обычный 35-45
> ваттный AMD Athlon 64 X2 3800+, вставляем в материнку в Socket
> AM2. В PCI-E вставляем взрослый сетевой адаптер...

изя, то, о чём ты тут пытаешься лечить - это делается на 82575/82576 и выше, которые igb.
ценник на такую карточку будет поболее цены этого атлона(тем более, что у атлончика кеш маленький, да и полоса по памяти скромная, так что люди берут i5/i7).

Далее. раз ты выходишь за рамки исходной задачи, хочу поведать, что pf умирает, если нахватается стейтов.

> Мне кажется, ты не совсем точно понимаешь функции пакетного фильтра. Скажу по
> секрету: для пакетного фильтра не важен размер содержимого пакета, PF работает
> с заголовками. ;)

изя, зачем писать о том, чего не понимаешь? пакетному фильтру как раз важен размер содержимого пакета, т.к. от этого зависит пакетрейт. гигабит пакетиками по 64 байта и гигабит пакетиками по 600байт - это совсем разные вещи.

А пакетные фильтры, работающие только с заголовками остались в прошлом веке.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

87. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 15-Апр-12, 10:35 
>[оверквотинг удален]
> Далее. раз ты выходишь за рамки исходной задачи, хочу поведать, что pf
> умирает, если нахватается стейтов.
>> Мне кажется, ты не совсем точно понимаешь функции пакетного фильтра. Скажу по
>> секрету: для пакетного фильтра не важен размер содержимого пакета, PF работает
>> с заголовками. ;)
> изя, зачем писать о том, чего не понимаешь? пакетному фильтру как раз
> важен размер содержимого пакета, т.к. от этого зависит пакетрейт. гигабит пакетиками
> по 64 байта и гигабит пакетиками по 600байт - это совсем
> разные вещи.
> А пакетные фильтры, работающие только с заголовками остались в прошлом веке.

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

88. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 15-Апр-12, 10:40 
>[оверквотинг удален]
>>>> А этот "гроб" переваривает за 1000 kpps.
>>> На атоме?
>> Кто сказал "атом"? В моём лексиконе такого слова нет. Берём обычный 35-45
>> ваттный AMD Athlon 64 X2 3800+, вставляем в материнку в Socket
>> AM2. В PCI-E вставляем взрослый сетевой адаптер...
> изя, то, о чём ты тут пытаешься лечить - это делается на
> 82575/82576 и выше, которые igb.
> ценник на такую карточку будет поболее цены этого атлона(тем более, что у
> атлончика кеш маленький, да и полоса по памяти скромная, так что
> люди берут i5/i7).

Абсолютно не верно. Вы пробовали Атлон на 10Гбитных картах. Его с головой хвататет. В тех ссылках что я скидывал об этом написано. На англицком правда. Главное не проц, а шина интерфейса на котором сидит сетевуха, а шина память-проц не узкой место для любого современного процессора. Мы говорим для задач роутера.

> Далее. раз ты выходишь за рамки исходной задачи, хочу поведать, что pf
> умирает, если нахватается стейтов.

И после этого вы будете говорить, что понимаете работу PF? Слабо в это вериться :-)

Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

90. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 15-Апр-12, 15:55 
> Абсолютно не верно. Вы пробовали Атлон на 10Гбитных картах. Его с головой
> хвататет. В тех ссылках что я скидывал об этом написано.

а вы сами пробовали? ;) у него маленький кэш и относительно невысокая производительность.
и какой смысл в такой несбалансированной системе, где сетевая карточка стоит несколько сотен баксов и процессор - сотню?

чуть пригрузите шейпером/натом и железка "умрёт".

>  И после этого вы будете говорить, что понимаете работу PF? Слабо
> в это вериться :-)

уважаемый Артём! Если вы с чем-то не согласны, попробуйте хоть как-то аргументировать свою точку зрения. Если вы считаете, что время state lookup в pf не зависит от числа стейтов - подтвердите это чем-то(например, рассказав про используемую структуру данных и время поиска/вставки/удаления элемента в ней).

afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd это несколько  иначе).

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

92. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 15-Апр-12, 23:42 
>> Абсолютно не верно. Вы пробовали Атлон на 10Гбитных картах. Его с головой
>> хвататет. В тех ссылках что я скидывал об этом написано.
> а вы сами пробовали? ;) у него маленький кэш и относительно невысокая
> производительность.
> и какой смысл в такой несбалансированной системе, где сетевая карточка стоит несколько
> сотен баксов и процессор - сотню?

Так не надо переводить сбалансированнсоть системы в баксовый вклад каждого компонента. Смотрите, если для определенных задачь требуется стобаксовая сетевая, хватает 60 баксового процессора и 10 баксвовой видеокарты, то вы считаете систему не сбалансированной. Система выполняет свои фугкции полностью и ни один компонент не является узким местов - вот принцип сбалансированности. Ваш подход к сбалансированности системе чисто юзерский).

> чуть пригрузите шейпером/натом и железка "умрёт".
>>  И после этого вы будете говорить, что понимаете работу PF? Слабо
>> в это вериться :-)
> уважаемый Артём! Если вы с чем-то не согласны, попробуйте хоть как-то аргументировать
> свою точку зрения. Если вы считаете, что время state lookup в
> pf не зависит от числа стейтов - подтвердите это чем-то(например, рассказав
> про используемую структуру данных и время поиска/вставки/удаления элемента в ней).

Зависит, но не так критично как вы думаете. Чисто из практики. По умолчанию кол-во стейтов ограничено 10000. Когда число стейтов будет равно 10000 ПФ будет нормально работать и не "умрет" как вы пишите. Но просто не будет создавать новые подключения. Что бы избежать подобных ситуаций есть адаптивный механизм регулировки  кол-ва стейтов. Я это использую на внешнев интерфейсе. Видел системы, построеные не мной, где кол-во было ограничено 200к и проблем с нагрузкой не было.

> afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd
> это несколько  иначе).

Во freebsd скоро совсем  будет иначе. Имею ввиду PF SMP friendly :-)

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

94. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 16-Апр-12, 03:31 
> Система выполняет свои фугкции полностью и ни один компонент не является
> узким местов - вот принцип сбалансированности. Ваш подход к сбалансированности системе
> чисто юзерский).

скажите, лично вы роутили 10 гигабит на PC?
для описанной вами в статье задаче достаточно dir-620 + openwrt.

хотя, раз вы всё пытаетесь оценить мой уровень, то в 2010 году вы задавали такие вопросы:

https://www.opennet.ru/openforum/vsluhforumID1/88075.html


>> уважаемый Артём! Если вы с чем-то не согласны, попробуйте хоть как-то аргументировать
>> свою точку зрения. Если вы считаете, что время state lookup в
>> pf не зависит от числа стейтов - подтвердите это чем-то(например, рассказав
>> про используемую структуру данных и время поиска/вставки/удаления элемента в ней).
> Зависит, но не так критично как вы думаете. Чисто из практики.

чисто из практики - это на forum.nag.ru
там вопрос выбора пакетного фильтра затёрт до дыр, даже профайлили его через hwpmc.

>По умолчанию кол-во стейтов ограничено 10000. Когда число стейтов будет равно 10000
> ПФ будет нормально работать и не "умрет" как вы пишите.

я писал про 600k стейтов. это в 60 раз больше дефолта, который вы озвучили.
600к набираются достаточно легко в сети не очень большого провайдера.

>Но просто не будет создавать новые подключения.

как мило. "дорогой пользователь, вы не можете сходить на любимый вконтактик, т.к. у нас на
NAS исчерпан лимит стейтов".

> Видел системы, построеные не мной, где кол-во было ограничено
> 200к и проблем с нагрузкой не было.

я ещё раз напоминаю про 600k стейтов :)
вообще, на стенде я создавал ~ 2млн стейтов.

>> afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd
>> это несколько  иначе).
> Во freebsd скоро совсем  будет иначе. Имею ввиду PF SMP friendly
> :-)

1)до этого далеко
2)на текущий момент всё и так работает в однопоточном режиме
3)glebius довольно сильно переписывает pf, так что скорее будет openbsd pf и freebsd pf, достаточно сильно между собой отличающиеся.

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

96. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 16-Апр-12, 10:36 
>> Система выполняет свои фугкции полностью и ни один компонент не является
>> узким местов - вот принцип сбалансированности. Ваш подход к сбалансированности системе
>> чисто юзерский).
> скажите, лично вы роутили 10 гигабит на PC?
> для описанной вами в статье задаче достаточно dir-620 + openwrt.

Непонятный ответ на мои утверждения о непонимании вами сбалансированной системы. Отвечайте по теме, а не переводите своим ответом вопрос в другую плоскость.

> хотя, раз вы всё пытаетесь оценить мой уровень, то в 2010 году
> вы задавали такие вопросы:
> https://www.opennet.ru/openforum/vsluhforumID1/88075.html

И что?

>[оверквотинг удален]
>>> про используемую структуру данных и время поиска/вставки/удаления элемента в ней).
>> Зависит, но не так критично как вы думаете. Чисто из практики.
> чисто из практики - это на forum.nag.ru
> там вопрос выбора пакетного фильтра затёрт до дыр, даже профайлили его через
> hwpmc.
>>По умолчанию кол-во стейтов ограничено 10000. Когда число стейтов будет равно 10000
>> ПФ будет нормально работать и не "умрет" как вы пишите.
> я писал про 600k стейтов. это в 60 раз больше дефолта, который
> вы озвучили.
> 600к набираются достаточно легко в сети не очень большого провайдера.

Уважаемый, для провайдерских задач совсем другие цели, а значит и конфигурация железа, выбор пакетного фильтра и т.д. и т.п. Не надо путать х. с ж.

>>Но просто не будет создавать новые подключения.
> как мило. "дорогой пользователь, вы не можете сходить на любимый вконтактик, т.к.
> у нас на
> NAS исчерпан лимит стейтов".
>> Видел системы, построеные не мной, где кол-во было ограничено
>> 200к и проблем с нагрузкой не было.
> я ещё раз напоминаю про 600k стейтов :)
> вообще, на стенде я создавал ~ 2млн стейтов.

Зачем тогда говорить про "умирающий" pf.

>>> afaik, в pf state table в openbsd защищена giant lock'ом(хотя, во freebsd
>>> это несколько  иначе).
>> Во freebsd скоро совсем  будет иначе. Имею ввиду PF SMP friendly
>> :-)
> 1)до этого далеко
> 2)на текущий момент всё и так работает в однопоточном режиме
> 3)glebius довольно сильно переписывает pf, так что скорее будет openbsd pf и
> freebsd pf, достаточно сильно между собой отличающиеся.

Примерно об этом я ранее говорил. Я в курсе.

https://www.opennet.ru/openforum/vsluhforumID1/93191.html#1


P.S.: А вообще у меня подозрение, что я каким-то образом задел ваше самолюбие и поставил под сомнение ваш проф. уровень, который вы считаете выше других.
Без обид:-)

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

91. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 15-Апр-12, 16:03 
и давайте всё-таки вы ответите на мой вопрос про voip.


Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

93. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 15-Апр-12, 23:44 
> и давайте всё-таки вы ответите на мой вопрос про voip.

А разве я вам не ответил ранее?

Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

95. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 16-Апр-12, 03:40 
>> и давайте всё-таки вы ответите на мой вопрос про voip.
> А разве я вам не ответил ранее?

в том и дело, что нет.

задача проста:
астериск на внешней площадке, 2 офиса(N1 & N2) с роутерами на pf и вашим конфигом.
сотрудник офиса N1 звонит своему коллеге в офис N2. на астериске directmedia/canreinvite=yes. надо дать голосу отдельный приоритет и отделить от торрентов по utp(который udp).

Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

97. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 16-Апр-12, 11:09 
>>> и давайте всё-таки вы ответите на мой вопрос про voip.
>> А разве я вам не ответил ранее?
> в том и дело, что нет.
> задача проста:
> астериск на внешней площадке, 2 офиса(N1 & N2) с роутерами на pf
> и вашим конфигом.
> сотрудник офиса N1 звонит своему коллеге в офис N2. на астериске directmedia/canreinvite=yes.
> надо дать голосу отдельный приоритет и отделить от торрентов по utp(который
> udp).

А в чем проблема-то. SIP/IAX телефоны в своем влане. Далее, все понятно?

Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

98. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 16-Апр-12, 14:39 
>>>> и давайте всё-таки вы ответите на мой вопрос про voip.
>>> А разве я вам не ответил ранее?
>> в том и дело, что нет.
>> задача проста:
>> астериск на внешней площадке, 2 офиса(N1 & N2) с роутерами на pf
>> и вашим конфигом.
>> сотрудник офиса N1 звонит своему коллеге в офис N2. на астериске directmedia/canreinvite=yes.
>> надо дать голосу отдельный приоритет и отделить от торрентов по utp(который
>> udp).
> А в чем проблема-то. SIP/IAX телефоны в своем влане. Далее, все понятно?

а в случае софт-телефонов?

ну а voice vlan - это выход, да. только к чему тогда такие сложности, если у каждого телефона свой ip-адрес и можно просто держать табличку с адресами телефонов?


Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

99. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 16-Апр-12, 15:15 
>[оверквотинг удален]
>>>> А разве я вам не ответил ранее?
>>> в том и дело, что нет.
>>> задача проста:
>>> астериск на внешней площадке, 2 офиса(N1 & N2) с роутерами на pf
>>> и вашим конфигом.
>>> сотрудник офиса N1 звонит своему коллеге в офис N2. на астериске directmedia/canreinvite=yes.
>>> надо дать голосу отдельный приоритет и отделить от торрентов по utp(который
>>> udp).
>> А в чем проблема-то. SIP/IAX телефоны в своем влане. Далее, все понятно?
> а в случае софт-телефонов?

Ну здесь да. Определенные сложности есть.
Вообще потихоньку тестирую ipfw+diffuse. Вот это решает такую проблему:)

> ну а voice vlan - это выход, да. только к чему тогда
> такие сложности, если у каждого телефона свой ip-адрес и можно просто
> держать табличку с адресами телефонов?

Да и так можно. А если топология сети к вланам привязана, то чеб этим не воспользоваться.

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

105. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 16-Апр-12, 21:57 
>[оверквотинг удален]
>>>> А разве я вам не ответил ранее?
>>> в том и дело, что нет.
>>> задача проста:
>>> астериск на внешней площадке, 2 офиса(N1 & N2) с роутерами на pf
>>> и вашим конфигом.
>>> сотрудник офиса N1 звонит своему коллеге в офис N2. на астериске directmedia/canreinvite=yes.
>>> надо дать голосу отдельный приоритет и отделить от торрентов по utp(который
>>> udp).
>> А в чем проблема-то. SIP/IAX телефоны в своем влане. Далее, все понятно?
> а в случае софт-телефонов?

Вопрос в догонку. А как вы решаете это с помощью Linux/netfilter?

Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

106. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 17-Апр-12, 08:23 
>>[оверквотинг удален]
>>> А в чем проблема-то. SIP/IAX телефоны в своем влане. Далее, все понятно?
>> а в случае софт-телефонов?
> Вопрос в догонку. А как вы решаете это с помощью Linux/netfilter?

элементарно. создание классов не привожу, это банально.

modprobe nf_conntrack_sip
modprobe nf_conntrack_ftp
iptables -t mangle -A POSTROUTING -p udp --dport 5060 -j CLASSIFY --set-class 1:10
iptables -t mangle -A POSTROUTING -m helper --helper sip -p udp -j CLASSIFY --set-class 1:10
iptables -t mangle -A POSTROUTING -m helper --helper ftp -p tcp -j CLASSIFY --set-class 1:20

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

102. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 16-Апр-12, 21:01 
> Абсолютно не верно. Вы пробовали Атлон на 10Гбитных картах. Его с головой хвататет.

Для чего? А слабо L7 filtering? Ну ладно, хотя-бы QoS более-менее нормальный? Про крутотень типа 64-битных пакетов говорить не будем, не садисты :)

Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

101. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Аноним (??) on 16-Апр-12, 20:58 
> Кто сказал "атом"? В моём лексиконе такого слова нет. Берём обычный 35-45
> ваттный AMD Athlon 64 X2 3800+, вставляем в материнку в Socket
> AM2. В PCI-E вставляем взрослый сетевой адаптер...

И получем здоровый жручий гроб с кучей вентилей норовящих забиться пылью, что особенно весело в БП. А чтоб 5 портов пиляемых вланами так и сяк на группы? И чтоб все это уложилось в ту же штуку деревяшек, за которые задача решаема? :)

> Мне кажется, ты не совсем точно понимаешь функции пакетного фильтра. Скажу по
> секрету: для пакетного фильтра не важен размер содержимого пакета, PF работает с заголовками. ;)

А мне кажется что это ты не совсем понял: заголовки занимают некоторое место, что накладывает некий вполне конкретный лимит на PPS на даденной скорости линка. Например, миллионный PPS ну никак не влезет в 5 Мбит линк. Там только для отсыла одних только протокольных заголовков надо бОльшую скорость. Внезазпно, да? :)

>> Да в общем то работает. Насчет десятка правда хз, но вообще -
>> пашет. Однако в исходной задаче вообще про это не говорится.
> Адью.

А потом кто-то удивляется когда им натурально именно адью и делают. Ибо только дятел может приволочь для решения задачи с которой справляется железка за штукарь огроменный писюк, сделать в разы дороже, жручее, занимая дофига места и убив в 10 раз больше времени на настройку. Победа над здравым смыслом.

Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

109. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от alex.h (??) on 23-Апр-12, 00:23 
>> Даже пакеты можно доустановить.
> Вот достижение! А на FreeBSD можно не только доустановить, но и собрать
> ПО с нужными опциями ШТАТНО. Сюрприз?

Вот плохо даже не то, что Вами тут написано, а то, что не написано!
В то время, как человек указывает на систему, которая после инсталляции даёт готовый маршрутизатор и может быть установлена внутрь SOHO-коробочки (а OpenWRT можно и на x86, на том же Атоме использовать), Вы ему рассказываете как это замечательно точить маршрутизатор из системы общего назначения вручную.
Вот лучше бы рассказали про BSDRP и pfSence! А так получается, что на аргументы об удобстве системы, которая позволяет быстро получить типовой функционал и по желанию его расширить, приводятся аргументы: зато посмотрите, какая свобода творчества - каждый раз результат уникален!

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

16. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 11-Апр-12, 15:57 

Ну это в этом случай такие скорости. А сколько есть провайдеров, предоставляющих Инет в десятки мегабит по кабелю к клиенту и несколько мегабит от него. Да в таком случае, если кто-то потянет с вас торрент, например, или вы будете заливать на аплоадер какой-нибудь файл, то вы толком даже страничку не загрузите. Так устроен ТСР...
Когда я начал на все роутеры внедрять в обязательном порядке QоS, я вам скажу, что качество работы пользователей в Инете значительно возросло.
Вот если у вас будет _гарантированный_ синхронный канал мегабит в 20, вот тогда можно и без приоритизации:-)
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

25. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 03:14 
> Ну это в этом случай такие скорости. А сколько есть провайдеров, предоставляющих
> Инет в десятки мегабит по кабелю к клиенту и несколько мегабит
> от него. Да в таком случае, если кто-то потянет с вас
> торрент, например, или вы будете заливать на аплоадер какой-нибудь файл, то
> вы толком даже страничку не загрузите. Так устроен ТСР...

1)форвардить сотню мегабит на современных SoC не проблема даже софтварно.
2)проблемы возникают из-за nat
3)современные SoC имеют на борту аппаратную акселерацию nat


> Когда я начал на все роутеры внедрять в обязательном порядке QоS, я
> вам скажу, что качество работы пользователей в Инете значительно возросло.
> Вот если у вас будет _гарантированный_ синхронный канал мегабит в 20, вот
> тогда можно и без приоритизации:-)

а что вы подразумеваете под синхронным каналом? SDH/PDH?

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

29. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +1 +/
Сообщение от ragus (ok) on 12-Апр-12, 09:45 
2 вопроса к автору:

1)какова судьба торрент-трафика и как вы его класифицируете?
2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 10:01 
> 2 вопроса к автору:
> 1)какова судьба торрент-трафика и как вы его класифицируете?
> 2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?

После таких вопросов я могу сделать вывод, что читали статью через строчку, соответсвенно таков и ответ.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

34. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +1 +/
Сообщение от ragus (ok) on 12-Апр-12, 10:04 
>> 2 вопроса к автору:
>> 1)какова судьба торрент-трафика и как вы его класифицируете?
>> 2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?
> После таких вопросов я могу сделать вывод, что читали статью через строчку,
> соответсвенно таков и ответ.

я то читал внимательно.
вы пишете:

>Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP.

и я в упор не вижу классификацию по протоколу. всё что вы делаете - это сливаете трафик от разных хостов в соотв. очередь, т.е. при запущенных торрентах мы гарантированно получим хлюпающий/булькающий голос в voip.


а вот вы, судя по всему, ответить затрудняетесь.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

35. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 13:05 
Еще раз внимательно читайте.
Трафик для сип пиров попадаеет в *_hipri, торрент в *_other, у каждой очереди своя _гарантированная_ полоса. Я потому и задействую ALTQ, что бы не было "бульканья", когда кто-то тянет торрент. Это практическая реально работатющая конфигурация.
А вы походу больше теоретик. Я же говорю поднимайте виртуалку смоделируйте, а потом будем спорить. Ок?
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

37. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +1 +/
Сообщение от ragus (ok) on 12-Апр-12, 13:16 
> Еще раз внимательно читайте.
> Трафик для сип пиров попадаеет в *_hipri, торрент в *_other, у каждой
> очереди своя _гарантированная_ полоса. Я потому и задействую ALTQ, что бы
> не было "бульканья", когда кто-то тянет торрент. Это практическая реально работатющая
> конфигурация.

в _hipri у вас попадёт только sip, но никак не rtp. rtp у вас попадёт в _other и будет делить полосу вместе с торрентами.

https у вас тоже свалится в _other.

> А вы походу больше теоретик. Я же говорю поднимайте виртуалку смоделируйте, а
> потом будем спорить. Ок?

я практик с опытом построения реально работающего call-центра с двумя офисами под операторов и факсами по g711(с t.38 тогда в астериске было совсем плохо).

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

39. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 13:23 
>> Еще раз внимательно читайте.
>> Трафик для сип пиров попадаеет в *_hipri, торрент в *_other, у каждой
>> очереди своя _гарантированная_ полоса. Я потому и задействую ALTQ, что бы
>> не было "бульканья", когда кто-то тянет торрент. Это практическая реально работатющая
>> конфигурация.
> в _hipri у вас попадёт только sip, но никак не rtp. rtp
> у вас попадёт в _other и будет делить полосу вместе с
> торрентами.
> https у вас тоже свалится в _other.

Блин. ну яж говорю через строчку читаете.

  pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        $mst queue (d_other d_ack) tag INET_OTHER

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port {20 21 25 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI

   pass in log on $int_if inet proto tcp from ($int_if:network) to !(self:network) \
        port 443 $mst queue (d_pri d_ack) tag INET_PRI

Да в идеале, использовать еще и HTTPS прокси, груповой политикой настроить клинтов, но не хотел с этим заморачиваться.


>> А вы походу больше теоретик. Я же говорю поднимайте виртуалку смоделируйте, а
>> потом будем спорить. Ок?
> я практик с опытом построения реально работающего call-центра с двумя офисами под
> операторов и факсами по g711(с t.38 тогда в астериске было совсем
> плохо).

А, пипетками буим меряться? :-)

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

41. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 13:26 
>[оверквотинг удален]
>         $mst queue (d_other d_ack)
> tag INET_OTHER
>    pass in log on $int_if inet proto tcp from
> ($int_if:network) to !(self:network) \
>         port {20 21 25
> 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI
>    pass in log on $int_if inet proto tcp from
> ($int_if:network) to !(self:network) \
>         port 443 $mst queue
> (d_pri d_ack) tag INET_PRI

и где тут RTP?

> А, пипетками буим меряться? :-)

мы же с вами профессионалы. давайте достанем и померяемся! (с)

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

43. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 13:33 
>[оверквотинг удален]
>> tag INET_OTHER
>>    pass in log on $int_if inet proto tcp from
>> ($int_if:network) to !(self:network) \
>>         port {20 21 25
>> 110 143 5190 8080 081} $mst queue (d_lowpri d_ack) tag INET_LOWPRI
>>    pass in log on $int_if inet proto tcp from
>> ($int_if:network) to !(self:network) \
>>         port 443 $mst queue
>> (d_pri d_ack) tag INET_PRI
> и где тут RTP?

Вот 2 правила, описывающие исходящее с внешнего интерфейса.

pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers> port 5060 queue u_hipri

pass out quick on $ext_if inet proto udp from ($ext_if) to any queue u_pri

В данном случае RTP будет попадать в u_pri, но ничто не мешает прописать так:

pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers> user asterisk queue u_hipri


Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

45. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 13:47 
> Вот 2 правила, описывающие исходящее с внешнего интерфейса.
> pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers>
> port 5060 queue u_hipri

ок, сигнализация ушла u_hipri

> pass out quick on $ext_if inet proto udp from ($ext_if) to any
> queue u_pri

ок, весь исходящий udp ушёл в u_pri

> В данном случае RTP будет попадать в u_pri, но ничто не мешает
> прописать так:
> pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers>
> user asterisk queue u_hipri

и оно будет работать не так, как вы ожидаете. указывая что-то в <sip_peers> вы с большой долей вероятности делаете это правило нерабочим.

объясню на примере sipnet.ru:

у него всего одна A-запись в днс для sipnet.ru:
sipnet.ru.        83668    IN    A    212.53.40.40

прописав в sip_peers адрес 212.53.40.40 вы никак не повлияете на голос. потому что rtp будет бегать между пирами напрямую, без проксирования.
т.е. если я звоню из спб в прагу, то rtp будет бегать между моим хостом и хостом где-то в чехии(аналогично с зимбабве, тимбукту итп)

да, астериск можно принудительно запретить ходить трафик напрямую, но адреса всех возможных пиров врядли вам известны(за исключением достаточно ограниченного числа случаев)

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

47. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 14:00 
>[оверквотинг удален]
> ок, сигнализация ушла u_hipri
>> pass out quick on $ext_if inet proto udp from ($ext_if) to any
>> queue u_pri
> ок, весь исходящий udp ушёл в u_pri
>> В данном случае RTP будет попадать в u_pri, но ничто не мешает
>> прописать так:
>> pass out quick on $ext_if inet proto udp from ($ext_if) to <sip_peers>
>> user asterisk queue u_hipri
> и оно будет работать не так, как вы ожидаете. указывая что-то в
> <sip_peers> вы с большой долей вероятности делаете это правило нерабочим.

Хорошо, согласен в RTP-трафике указывать адрес не нужно. Достаточно указать пользователя asterisk.

Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

48. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 14:04 
> Хорошо, согласен в RTP-трафике указывать адрес не нужно. Достаточно указать пользователя
> asterisk.

1)работать будет только при canreinvite=no
2)сломается при выносе астериска на отдельную машину

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

49. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 14:22 
>> Хорошо, согласен в RTP-трафике указывать адрес не нужно. Достаточно указать пользователя
>> asterisk.
> 1)работать будет только при canreinvite=no

Вы еще на Астере 1.4? Пора оперировать directmedia

> 2)сломается при выносе астериска на отдельную машину

Абсолютно ничего не сломается. Если машинка внутресетевая, то просто надо будет грамотно настроить тегирование. А потом с внешнего интерфейса его в нужную очередь направить.

Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

50. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 15:04 
>> 2)сломается при выносе астериска на отдельную машину
> Абсолютно ничего не сломается. Если машинка внутресетевая, то просто надо будет грамотно
> настроить тегирование. А потом с внешнего интерфейса его в нужную очередь
> направить.

а можно подробнее, как вы его настроите? заранее неизвестно какие порты будут использоваться для rtp-трафика, т.е. остаётся только вариант с повышением приоритета для всего udp-трафика.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

52. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 18:05 
>>> 2)сломается при выносе астериска на отдельную машину
>> Абсолютно ничего не сломается. Если машинка внутресетевая, то просто надо будет грамотно
>> настроить тегирование. А потом с внешнего интерфейса его в нужную очередь
>> направить.
> а можно подробнее, как вы его настроите? заранее неизвестно какие порты будут
> использоваться для rtp-трафика, т.е. остаётся только вариант с повышением приоритета для
> всего udp-трафика.

Допустим корпоративный отдельный Aster (впринципе так и нужно делать, кроме него там ничего не должно быть), тогда пришедший от него udp тегируем и на внешнем интерфейсе маршрутизатора отправляем к пиру. Весь остальной udp с BPX просто рубим, ну кроме ДНС ессно.
НУ как-то так. Правила в лом писать, но это не проблема.

А вообще вы одни вопросы задаете, а каково ваше предложение?

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

55. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 23:22 

> Допустим корпоративный отдельный Aster (впринципе так и нужно делать, кроме него там
> ничего не должно быть), тогда пришедший от него udp тегируем и
> на внешнем интерфейсе маршрутизатора отправляем к пиру. Весь остальной udp с
> BPX просто рубим, ну кроме ДНС ессно.

вообще, держать на роутере какие-либо сервисы - моветон :)
а с directmedia=yes ваш вариант не рабочий.

> А вообще вы одни вопросы задаете, а каково ваше предложение?

а я аккуратно подвожу к тому, что существуют межсетевые экраны, умеющие разглядывать payload пакета и правильно строить трансляции.

ненавидимый многими вышеупомянутый netfilter умеет анализировать SDP в SIP INVITE и добавлять в state table записи для корректного прохождения/трансляции RTP.
аналогично с FTP/H.323/PPTP.

могли взять ipfw и не иметь подобных проблем.

Кстати, вы в качестве workaround'а пытаетесь использовать тот факт, что заведомо известен адрес одного из пиров. как я уже упоминал, с directmedia/canreinvite=yes работать оно не будет.

есть ещё один вариант, при котором будут проблемы: asterisk стоит в локальной сети за nat.
при входящем звонке из внешнего мира у вас, скорее всего, будет односторонняя слышимость.

Решая вашу задачу я бы отталкивался от разделения трафика на "короткий" и "долгоиграющий" + приоритеты + классификация.

короткоживущим tcp-соединениям я бы давал чуть больший приоритет и полосу. "долгоиграющий", наоборот, уходил бы в низкий приоритет.
это позволит поднять субъективную скорость интернет-соединения + закачки не будут мешать всему остальному трафику.


Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

64. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 07:51 
>[оверквотинг удален]
>> на внешнем интерфейсе маршрутизатора отправляем к пиру. Весь остальной udp с
>> BPX просто рубим, ну кроме ДНС ессно.
> вообще, держать на роутере какие-либо сервисы - моветон :)
> а с directmedia=yes ваш вариант не рабочий.
>> А вообще вы одни вопросы задаете, а каково ваше предложение?
> а я аккуратно подвожу к тому, что существуют межсетевые экраны, умеющие разглядывать
> payload пакета и правильно строить трансляции.
> ненавидимый многими вышеупомянутый netfilter умеет анализировать SDP в SIP INVITE и добавлять
> в state table записи для корректного прохождения/трансляции RTP.
> аналогично с FTP/H.323/PPTP.

Мне на ум приходит мысл, что вы просто не разобрались в работе пакетного фильра. Отсутствия опыта работы с ним и приводит к таким заблуждениям. Пользуйтесь своим линухом, iptables'ом, а я буду пользоваться качественным и надежным решением.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

67. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 15:17 
>  Мне на ум приходит мысл, что вы просто не разобрались в
> работе пакетного фильра. Отсутствия опыта работы с ним и приводит к
> таким заблуждениям.

ага, с учётом того, что я пользовался pf'ом ещё с момента его портирования во freebsd.
вы так и не сказали, как вы отделяете торренты от неторрентов. тем более, что если они у вас бегают через utp и попадают в один класс вместе с voip-трафиком.

>Пользуйтесь своим линухом, iptables'ом, а я буду пользоваться качественным
> и надежным решением.

мне вот кажется, что это вы не понимаете sip call flow.

допустим, у компании распределённая сеть филиалов на территории рф и 2 серверные площадки: в спб и мск с астериском на каждой. астериски объединены через dundi+iax и светят в мир адресом, допустим, 213.21.44.10, directmedia/canreinvite=yes

в филиалах никаких астерисков нет, стоят роутеры на pf в вашей конфигурации.

Человек из филиала в Казани совершает звонок коллеге из Самары. Как при этом побежит трафик и что вы тут будете тегировать?

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

70. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 13-Апр-12, 18:50 
>>  Мне на ум приходит мысл, что вы просто не разобрались в
>> работе пакетного фильра. Отсутствия опыта работы с ним и приводит к
>> таким заблуждениям.
> ага, с учётом того, что я пользовался pf'ом ещё с момента его
> портирования во freebsd.

Это не аргумент. Я в опенке еще ipf видел, кстати потом по инерции им еще на Фре пользовался.

> вы так и не сказали, как вы отделяете торренты от неторрентов. тем
> более, что если они у вас бегают через utp и попадают
> в один класс вместе с voip-трафиком.
>>Пользуйтесь своим линухом, iptables'ом, а я буду пользоваться качественным
>> и надежным решением.
> мне вот кажется, что это вы не понимаете sip call flow.

Все я понимаю. Вы хотите проверить мои знания в Астере. Ну вот осталось прикрутить вэб морду к биллингу для voip одной небольшой гостиницы.
А вы понимаете?

> допустим, у компании распределённая сеть филиалов на территории рф и 2 серверные
> площадки: в спб и мск с астериском на каждой. астериски объединены
> через dundi+iax и светят в мир адресом, допустим, 213.21.44.10, directmedia/canreinvite=yes
> в филиалах никаких астерисков нет, стоят роутеры на pf в вашей конфигурации.
> Человек из филиала в Казани совершает звонок коллеге из Самары. Как при
> этом побежит трафик и что вы тут будете тегировать?

Чесно терпение потихоньку заканчивается, нет времени вникать в ваши например. Ответ короткий - не тегированным едины....

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

73. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 13-Апр-12, 19:48 
>> мне вот кажется, что это вы не понимаете sip call flow.
> Все я понимаю. Вы хотите проверить мои знания в Астере. Ну вот
> осталось прикрутить вэб морду к биллингу для voip одной небольшой гостиницы.

и? какое это отношение имеет к call flow? я рулил биллингом на 38млн абонентов, но лишь примерно представляю call flow в gsm сети, допустим, при наличии IN-платформы.

>> допустим, у компании распределённая сеть филиалов на территории рф и 2 серверные
>> площадки: в спб и мск с астериском на каждой. астериски объединены
>> через dundi+iax и светят в мир адресом, допустим, 213.21.44.10, directmedia/canreinvite=yes
>> в филиалах никаких астерисков нет, стоят роутеры на pf в вашей конфигурации.
>> Человек из филиала в Казани совершает звонок коллеге из Самары. Как при
>> этом побежит трафик и что вы тут будете тегировать?
> Чесно терпение потихоньку заканчивается, нет времени вникать в ваши например. Ответ короткий

два клиента за pfnat и sip proxy где-то в диком интернете, чего тут вникать?

приведённый пример - никакой не rocket science, всего лишь вынесенный на внешнюю площадку астериск. самый частый пример такого - это арендованная "виртуальная АТС".
при этом в обработке voip-трафика от положения астериска ничего не меняется.

> - не тегированным едины....

конкретика? проблеме прохождения "сложных" протоколов через statefull firewall/nat далеко не один год.

Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

112. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от Dmitriy (??) on 29-Окт-12, 15:01 
>[оверквотинг удален]
>> BPX просто рубим, ну кроме ДНС ессно.
> вообще, держать на роутере какие-либо сервисы - моветон :)
> а с directmedia=yes ваш вариант не рабочий.
>> А вообще вы одни вопросы задаете, а каково ваше предложение?
> а я аккуратно подвожу к тому, что существуют межсетевые экраны, умеющие разглядывать
> payload пакета и правильно строить трансляции.
> ненавидимый многими вышеупомянутый netfilter умеет анализировать SDP в SIP INVITE и добавлять
> в state table записи для корректного прохождения/трансляции RTP.
> аналогично с FTP/H.323/PPTP.
> могли взять ipfw и не иметь подобных проблем.

И как же вы с помощью ipfw payload будете разглядывать? Насколько я знаю он это не умеет.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

84. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от Аноним (??) on 14-Апр-12, 17:40 
> всего udp-трафика.

uTP будет рад :)

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

89. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 15-Апр-12, 11:32 

И что вам этот uTP? На 100 мегабитах роутер его не ощущает. Для магистрального коммутатора это может быть проблемой.
Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

103. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от Аноним (??) on 16-Апр-12, 21:04 
> И что вам этот uTP? На 100 мегабитах роутер его не ощущает.

Да ну? Этот чудный протоколец умеет ломовой PPS устраивать на радость софтороутерам. А вы предлагаете его приоретизнуть? Прикольная идея :)


Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

111. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от Аноним (??) on 27-Окт-12, 20:25 
А больше на ЛОХА похож
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

38. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 13:19 
>[оверквотинг удален]
>>> 1)какова судьба торрент-трафика и как вы его класифицируете?
>>> 2)какова судьба https-трафика? как я понимаю, его ждёт судьба торрентов?
>> После таких вопросов я могу сделать вывод, что читали статью через строчку,
>> соответсвенно таков и ответ.
> я то читал внимательно.
> вы пишете:
>>Трафик классифицируется как относительно сервиса/протокола (HTTP, FTP, Torrent) так и относительно пользователя, т.е. трафик от/к компьютера, например, бухгалтера может быть весь помечен как с высоким приоритетом, независимо от того Торрент это или FTP.
> и я в упор не вижу классификацию по протоколу. всё что вы
> делаете - это сливаете трафик от разных хостов в соотв. очередь,
> т.е. при запущенных торрентах мы гарантированно получим хлюпающий/булькающий голос в voip.

Смотрите. Трафик весь идет с высоким приоритетом (hipri) для отдельных хостов, потому что эти пользователи гарантированно торент качать не будут. Стоит система клиент-банк и всякие там отчетности в налоговую\ПФ и т.д. Да в эту очередь я направляю траф к сип пирам, который класифицируется протоколом, портом и адресами назначения. Торрент, восновном - это UDP с портами > 1024 - это очередь *_other, через ТСР\80 не пройдет, так как там прозрачный прокси.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

40. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 13:23 
> Да в эту
> очередь я направляю траф к сип пирам, который класифицируется протоколом, портом
> и адресами назначения.

вы туда направляете только сигнализацию, но никак не пакетики с голосом.
всё что вы таким образом добиваетесь - это потенциально более быстрое установление/завершение сессии итп. на качество голоса это никак не повлияет и в вашем варианте он будет булькать/хлюпать итп.

> Торрент, восновном - это UDP с портами >

торрент - это tcp. utp провайдеры режут достаточно успешно.

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

44. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от artemrts (ok) on 12-Апр-12, 13:37 

> торрент - это tcp. utp провайдеры режут достаточно успешно.

Совершенно ошибочное мнение. У меня процент ТСР трафика торрента не более 20. Мониторил через ng_netflow + pmacct

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

46. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от ragus (ok) on 12-Апр-12, 13:49 
>> торрент - это tcp. utp провайдеры режут достаточно успешно.
> Совершенно ошибочное мнение. У меня процент ТСР трафика торрента не более 20.
> Мониторил через ng_netflow + pmacct

а как вы отличаете торрент от не торрента? :)
и в таком случае по вашим же правилам торрент свалится в u_pri вместе c rtp.

Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

104. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от Аноним (??) on 16-Апр-12, 21:06 
> торрент - это tcp. utp провайдеры режут достаточно успешно.

Во первых, не все провы, а только мелкотравчатые мелкие локалки с черти-чем вместо роутеров.
Во вторых, оно первым делом сносит роутеры у хомяков, что способствует росту их мощности :)
В третьих, в бсдах он не то чтобы тривиально режется :)

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

110. "Раздел полезных советов: Маршрутизатор на базе FreeBSD с при..."  +/
Сообщение от XoRe (ok) on 07-Май-12, 23:16 
>> торрент - это tcp. utp провайдеры режут достаточно успешно.
> Во первых, не все провы, а только мелкотравчатые мелкие локалки с черти-чем
> вместо роутеров.

Ага.
Qwerty (Москва) и Beeline (там же).

> Во вторых, оно первым делом сносит роутеры у хомяков, что способствует росту
> их мощности :)

Роутеры у хомяков часто вполне осиляют, конечно, если канал не сильно большой.

> В третьих, в бсдах он не то чтобы тривиально режется :)

В бсдах как раз есть очень эффективный механизм в виде ng_bpf, который позволяет L7 фильтрацию.
Конкретно для uTP:
http://vurd.name/2011/09/03/%D0%B1%D0%BB.../

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

113. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Андрей (??) on 18-Июл-13, 09:04 
Подскажите пожалуйста, как правильно прописать ограничение по скорости при ширине канала в 15-20 Мегабит?
Заранее благодарен.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

114. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от artemrts (ok) on 18-Июл-13, 10:15 
> Подскажите пожалуйста, как правильно прописать ограничение по скорости при ширине канала
> в 15-20 Мегабит?
> Заранее благодарен.

А разве в статье об этом не сказано?

Назначаем очередь на внешнем интерфейсе. Величина bandwidth должна быть 96% от предоставляемой вышестоящим роутером. Здесь же перечисляем все дочерние очереди.

   altq on $ext_if hfsc bandwidth 800Kb queue ...

Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

115. "Маршрутизатор на базе FreeBSD с приоритизация трафика средст..."  +/
Сообщение от Андрей (??) on 23-Июл-13, 16:29 
Пробовал, но при загрузке правил вылетает вот такие ошибки
pfctl: the sum of the child bandwidth higher than parent "root_bce1"
pfctl: linkshare sc exceeds parent's sc
/etc/pf.conf:65: errors in queue definition
parent inetq not found for d_std
/etc/pf.conf:66: errors in queue definition
parent inetq not found for d_ack
/etc/pf.conf:67: errors in queue definition
parent inetq not found for d_dns
/etc/pf.conf:68: errors in queue definition
parent inetq not found for d_hipri
/etc/pf.conf:69: errors in queue definition
parent inetq not found for d_pri
/etc/pf.conf:70: errors in queue definition
parent inetq not found for d_lowpri
/etc/pf.conf:71: errors in queue definition
parent inetq not found for d_other
/etc/pf.conf:72: errors in queue definition
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру