https://opennet.ru/openforum/vsluhforumID3/83997.html Проблема приоритизации трафика, на мой взгляд, весьма актуальна. Интернет-канала много не бывает и на всех пользователей и сервисов локальной зачастую не хватает. Поэтому для нормальной работы Интернета требуется грамотное распределения полосы с учетом потребностей каждого из участников. Единственный раз, когда мне не понадобился QoS - это гарантированный провайдером канал в 20 Мбит/с в мир и 100Мбит/с - национальный. Но такое удовольствие не из дешевых, поэтому зачастую народ довольствуется ADSL-каналом с заявленной скоростью к клиенту до 5-10 Мбит/с.<br><br>Хочу заметить, что данная статья не предназначенная для новичков в сетевом администрировании в целом и в PF в частности. Читателю необходимо иметь минимальные навыки работы с сетями (понимать устройство пакета, знать что такое ТСР-флаги и т.д.), а также с пакетным фильтром PF. Не лишним будет прочесть официальный FAQ и man'ы. В основном цель этой статьи поделиться опытом, выслушать замечания и, возможно, улучшить свой вариант.<br><br>И так, постановка задачи: ор https://opennet.ru/openforum/vsluhforumID3/83997.html#115 Tue, 23 Jul 2013 12:29:39 GMT Пробовал, но при загрузке правил вылетает вот такие ошибки<br>pfctl: the sum of the child bandwidth higher than parent "root_bce1"<br>pfctl: linkshare sc exceeds parent's sc<br>/etc/pf.conf:65: errors in queue definition<br>parent inetq not found for d_std<br>/etc/pf.conf:66: errors in queue definition<br>parent inetq not found for d_ack<br>/etc/pf.conf:67: errors in queue definition<br>parent inetq not found for d_dns<br>/etc/pf.conf:68: errors in queue definition<br>parent inetq not found for d_hipri<br>/etc/pf.conf:69: errors in queue definition<br>parent inetq not found for d_pri<br>/etc/pf.conf:70: errors in queue definition<br>parent inetq not found for d_lowpri<br>/etc/pf.conf:71: errors in queue definition<br>parent inetq not found for d_other<br>/etc/pf.conf:72: errors in queue definition<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#114 Thu, 18 Jul 2013 06:15:00 GMT &gt; Подскажите пожалуйста, как правильно прописать ограничение по скорости при ширине канала <br>&gt; в 15-20 Мегабит?<br>&gt; Заранее благодарен.<br><br>А разве в статье об этом не сказано?<br><br>Назначаем очередь на внешнем интерфейсе. Величина bandwidth должна быть 96% от предоставляемой вышестоящим роутером. Здесь же перечисляем все дочерние очереди.<br><br> altq on $ext_if hfsc bandwidth 800Kb queue ...<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#113 Thu, 18 Jul 2013 05:04:48 GMT Подскажите пожалуйста, как правильно прописать ограничение по скорости при ширине канала в 15-20 Мегабит?<br>Заранее благодарен.<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#112 Mon, 29 Oct 2012 11:01:53 GMT &gt;[оверквотинг удален]<br>&gt;&gt; BPX просто рубим, ну кроме ДНС ессно.<br>&gt; вообще, держать на роутере какие-либо сервисы - моветон :) <br>&gt; а с directmedia=yes ваш вариант не рабочий.<br>&gt;&gt; А вообще вы одни вопросы задаете, а каково ваше предложение?<br>&gt; а я аккуратно подвожу к тому, что существуют межсетевые экраны, умеющие разглядывать <br>&gt; payload пакета и правильно строить трансляции.<br>&gt; ненавидимый многими вышеупомянутый netfilter умеет анализировать SDP в SIP INVITE и добавлять <br>&gt; в state table записи для корректного прохождения/трансляции RTP.<br>&gt; аналогично с FTP/H.323/PPTP.<br>&gt; могли взять ipfw и не иметь подобных проблем.<br><br> И как же вы с помощью ipfw payload будете разглядывать? Насколько я знаю он это не умеет.<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#111 Sat, 27 Oct 2012 16:25:26 GMT А больше на ЛОХА похож<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#110 Mon, 07 May 2012 19:16:01 GMT &gt;&gt; торрент - это tcp. utp провайдеры режут достаточно успешно.<br>&gt; Во первых, не все провы, а только мелкотравчатые мелкие локалки с черти-чем <br>&gt; вместо роутеров.<br><br>Ага.<br>Qwerty (Москва) и Beeline (там же).<br><br>&gt; Во вторых, оно первым делом сносит роутеры у хомяков, что способствует росту <br>&gt; их мощности :) <br><br>Роутеры у хомяков часто вполне осиляют, конечно, если канал не сильно большой.<br><br>&gt; В третьих, в бсдах он не то чтобы тривиально режется :) <br><br>В бсдах как раз есть очень эффективный механизм в виде ng_bpf, который позволяет L7 фильтрацию.<br>Конкретно для uTP:<br>http://vurd.name/2011/09/03/%D0%B1%D0%BB%D0%BE%D0%BA%D0%B8%D1%80%D0%BE%D0%B2%D0%BA%D0%B0-utp-%D0%BD%D0%B0-freebsd-%D1%87%D0%B5%D1%80%D0%B5%D0%B7-ng_bpf/<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#109 Sun, 22 Apr 2012 20:23:42 GMT &gt;&gt; Даже пакеты можно доустановить.<br>&gt; Вот достижение! А на FreeBSD можно не только доустановить, но и собрать <br>&gt; ПО с нужными опциями ШТАТНО. Сюрприз?<br><br>Вот плохо даже не то, что Вами тут написано, а то, что не написано!<br>В то время, как человек указывает на систему, которая после инсталляции даёт готовый маршрутизатор и может быть установлена внутрь SOHO-коробочки (а OpenWRT можно и на x86, на том же Атоме использовать), Вы ему рассказываете как это замечательно точить маршрутизатор из системы общего назначения вручную.<br>Вот лучше бы рассказали про BSDRP и pfSence! А так получается, что на аргументы об удобстве системы, которая позволяет быстро получить типовой функционал и по желанию его расширить, приводятся аргументы: зато посмотрите, какая свобода творчества - каждый раз результат уникален!<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#108 Sun, 22 Apr 2012 11:56:48 GMT Вроде бы тут раньше уже как-то обсуждали аппаратную акселерацию NAT, получалось что проц разгружается, но возможностей по обработке пакетов и поддержке протоколов (вроде ppoe/pptp) становится меньше. При таком раскладе не однозначный плюс получается, т.е. где-то плюс, а где-то - не очень.<br> https://opennet.ru/openforum/vsluhforumID3/83997.html#107 Sun, 22 Apr 2012 11:11:58 GMT &gt; у soho-железок длинка одна беда - это прошивка, которая решается с помощью openwrt.<br><br>Ради правды, у указанного класса железок две беды, вторая БП - который сначала греется, потом - умирает. Впрочем, раньше и сами железки грелись.<br>