acid Опубликовано 11 декабря, 2012 · Жалоба Возможно, этот вопрос уже подымался, если да, прошу прощения за дубликат. Этот скрипт расчитан на шепйинг-полисинг исключительно на двух интерфейсах, in и out? Что делать, если их больше, и они 802.1q vlan-ы, ставить отдельный тазик на бордер с кваггой и отдельный на шейпер с этим скриптом? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dee Опубликовано 11 декабря, 2012 · Жалоба Возможно, этот вопрос уже подымался, если да, прошу прощения за дубликат. Этот скрипт расчитан на шепйинг-полисинг исключительно на двух интерфейсах, in и out? Что делать, если их больше, и они 802.1q vlan-ы, ставить отдельный тазик на бордер с кваггой и отдельный на шейпер с этим скриптом? могу предложить вариант с использованием IMQ , когда создав два виртуальных интерфейса мы через iptables уже заворачиваем необходимый трафик дял шейпа в эти интерфейсы и всё будет резаться . Пример : вход (куча ppp+) , выход 1 - локалка 1Ж vlan1 , выход 2 (инет для ната) vlan2 , выход 3 (инет для реальников) vlan3 . sc настраиваем по умолчанию под shaper u32 in/out=IMQ(X) , потом уже в iptables вносим правила iptables -t mangle -I FORWARD -i ppp+ -o vlan2 -j IMQ --to-dev 0 и обратное iptables -t mangle -I FORWARD -i vlan2 -o ppp+ -j IMQ --to-dev 1 , такое же для vlan2 , а vlan1 будет к примеру гоняться без шейпера т.к локал , вобщем вариантов мносто милллион. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
acid Опубликовано 11 декабря, 2012 · Жалоба могу предложить вариант с использованием IMQ , когда создав два виртуальных интерфейса мы через iptables уже заворачиваем необходимый трафик дял шейпа в эти интерфейсы и всё будет резаться . Пример : вход (куча ppp+) , выход 1 - локалка 1Ж vlan1 , выход 2 (инет для ната) vlan2 , выход 3 (инет для реальников) vlan3 . sc настраиваем по умолчанию под shaper u32 in/out=IMQ(X) , потом уже в iptables вносим правила iptables -t mangle -I FORWARD -i ppp+ -o vlan2 -j IMQ --to-dev 0 и обратное iptables -t mangle -I FORWARD -i vlan2 -o ppp+ -j IMQ --to-dev 1 , такое же для vlan2 , а vlan1 будет к примеру гоняться без шейпера т.к локал , вобщем вариантов мносто милллион. так сейчас и сделано, с imq/iptables mangle mark/htb, но при объемах порядка 1.5гбит дуплекса (большой класс - 700мегабит и десяток помельче), шейпер начинает подтормаживать, растут задержки транзитного трафика, снимаешь шейпер - все нормально, применением u32/ipset мы значительно увеличим производительность? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 11 декабря, 2012 (изменено) · Жалоба Лучше не смешивать шейпинг с intervlan routing и поставить отдельную машину как шейпирующий мост. Псевдоустройства становятся узким местом при скоростях более гигабита. применением u32/ipset мы значительно увеличим производительность? Я никогда не пользовался iptables marks для классификации, поэтому не знаю. Очевидно, что хэш-фильтры u32 -- это наиболее быстрый метод классификации. В случае u32 ipset не нужен. Он имеет смысл только при использовании фильтра flow, т.к. в этом случае нельзя блокировать IP-адреса средствами tc, все пакеты так или иначе проходят через фильтр. Изменено 11 декабря, 2012 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
acid Опубликовано 11 декабря, 2012 · Жалоба Лучше не смешивать шейпинг с intervlan routing и поставить отдельную машину как шейпирующий мост. Псевдоустройства становятся узким местом при скоростях более гигабита. Спасибо за совет, т.е. топология будет где-то такая L3-свич агрегации -- Shaper (n x GE bond_in - n x GE bond_out) -- border (bgp) Какая ориентировочная производительсность такой схемы - сколько гигабит вытянет - 3,5,7? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 11 декабря, 2012 (изменено) · Жалоба Спасибо за совет, т.е. топология будет где-то такая L3-свич агрегации -- Shaper (n x GE bond_in - n x GE bond_out) -- border (bgp) Какая ориентировочная производительсность такой схемы - сколько гигабит вытянет - 3,5,7? Теоретически, может вытянуть столько же, сколько способен маршрутизировать. Если есть желание, можно поэкспериментировать с сетевухами на 10 Гбит. Однако, больше двух гигабит мне видеть не приходилось. При количестве пользователей, которое способно потреблять >2 Гб/с, у людей уже достаточно денег на какие-то фирменные решения, вроде SCE 8000. Изменено 11 декабря, 2012 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dee Опубликовано 13 декабря, 2012 · Жалоба не совсем понял как заюзать патч и с какой версией , поясните , очень необходима возможность добавлять в один класс несколько ip . а вообще сразу бы сетками 127.0.0.0/8 (пример) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 13 декабря, 2012 (изменено) · Жалоба не совсем понял как заюзать патч и с какой версией , поясните , очень необходима возможность добавлять в один класс несколько ip . а вообще сразу бы сетками 127.0.0.0/8 (пример) Патч есть на предыдущей странице. Если с помощью программы patch он не накладывается на последнюю версию, то надо в редакторе найти строки, которые начинаются с "-", и заменить на строки, начинающиеся с "+". Добавлять подсети тоже можно, если дописать код, чтобы в базе хранились еще и маски. Сейчас реализован шейпинг для отдельных IP-адресов. Изменено 13 декабря, 2012 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dee Опубликовано 14 декабря, 2012 · Жалоба что то я не в восторге от патча , все время нужно указывать id для каждого правила и ничего не объединяется под одним id а банально подменяется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 14 декабря, 2012 · Жалоба С несколькими IP на один класс слишком много проблем возникает, поэтому я не стал реализовывать эту схему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 14 декабря, 2012 · Жалоба что то я не в восторге от патча , все время нужно указывать id для каждого правила и ничего не объединяется под одним id а банально подменяется. Чтобы не подменялось, нужно в некоторых местах заменить $TC->("... replace ...") на $TC->("... add ..."). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saff1000 Опубликовано 29 января, 2013 · Жалоба Добрый день, поднят bridge на двух интерфейсах, запускаю sc-1.3.5, все нормально шейпится, но DHCP пакетики перестают проходить, подскажите пожалуйста, куда копнуть. Спасибо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 29 января, 2013 (изменено) · Жалоба Правило, блокирующее весь трафик, для которого не созданы фильтры, создается в строках 1348-1351 (файл sc). # block all other traffic $TC->( "filter add dev $dev parent 1:0 protocol ip pref $pref_default ". 'u32 match u32 0 0 at 0 police mtu 1 action drop' ); Перед этим правилом нужно создать отдельный класс и фильтр, разрешающие прохождение DHCP-трафика (UDP, порты 67, 68). Формат пакетов описан здесь: https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Technical_details Потом, если будет время, напишу правила в явном виде. Изменено 29 января, 2013 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saff1000 Опубликовано 29 января, 2013 · Жалоба Потом, если будет время, напишу правила в явном виде. Если вас не затруднит... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
minderm Опубликовано 31 января, 2013 · Жалоба У меня возникла странная пролема в работе. Скачал новую версию 1.3.5, стал конфигуроровать. Но при запуске не содаются правила, отладка показала , что не доходит до вызова функции tc_sys. Сталкивался кто-нибудь с этим? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saff1000 Опубликовано 31 января, 2013 · Жалоба minderm, а какие ошибки при этом, у меня все прошло гладко. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 31 января, 2013 · Жалоба У меня возникла странная пролема в работе. Скачал новую версию 1.3.5, стал конфигуроровать. Но при запуске не содаются правила, отладка показала , что не доходит до вызова функции tc_sys. Сталкивался кто-нибудь с этим? Укажите правильный путь к исполняемому файлу tc. Я поменял его на дефолтный /sbin/tc, потому что в новых дистрибутивах tc уже достаточно новый и его не надо собирать из исходников. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 2 февраля, 2013 · Жалоба Я почему-то сразу не подумал, а зачем вообще нужно через шейпирующий мост пропускать DHCP и прочий широковещательный трафик? Это неправильный дизайн сети. Почему бы просто не поставить DHCP-сервер внутри сети, т.е. до шейпера? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
replicant Опубликовано 3 февраля, 2013 (изменено) · Жалоба При количестве пользователей, которое способно потреблять >2 Гб/с, у людей уже достаточно денег на какие-то фирменные решения, вроде SCE 8000. Я бы сказал что порог приобретения для SCE 8000 начинается при 8-9 Гб/с потребления и то это достаточно больно ударяет по бюджету. А 2-3 Гб/с - это вообще-то еще объемы пионернетов, которым точно такое железо не по карману да и нет необходимости, потому что такой поток обрабатывается на паре тазиков, которые стоят вместе в 50-60 раз дешевле SCE 8000. Рекламные слоганы манагеров Циско-продаванов просто убивают: Решение SCE может позволить провайдерам услуг повысить свой доход на базе существующей инфраструктуры. Так и хочется послать подальше с таким подходом. Доход повышается напрямую и гарантированно только в двух случаях: - рост абонентской базы (здесь SCE ни разу не поможет) - ввод новых востребованных услуг (вопрос каких и при чем тут SCE?) Есть еще один способ - рост тарифов, но покажите мне оператора, который на территории РФ поднимал тарифы стабильно и регулярно в течение последних 2-3 лет? В данном случае (2-4 Гб/с аплинка) SCE - отличный способ просрать средства, которые можно было бы вложить с пользой. Изменено 3 февраля, 2013 пользователем replicant Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 4 февраля, 2013 (изменено) · Жалоба В данном случае (2-4 Гб/с аплинка) SCE - отличный способ просрать средства, которые можно было бы вложить с пользой. Честно говоря, я тоже не являюсь сторонником такого подхода. Если есть возможность сделать open source-решение, которое работает не хуже и выполняет требуемые функции, то нет смысла тратить деньги на переоцененное железо. Иногда конторы ищут не сетевых инженеров, которые могут работать с чем угодно, а узких специалистов по Cisco. Такими проще управлять в силу большей взаимозаменяемости. Плюс к этому, фирменное оборудование -- это понты и предмет гордости. Изменено 4 февраля, 2013 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saff1000 Опубликовано 4 февраля, 2013 (изменено) · Жалоба Я почему-то сразу не подумал, а зачем вообще нужно через шейпирующий мост пропускать DHCP и прочий широковещательный трафик? Это неправильный дизайн сети. Почему бы просто не поставить DHCP-сервер внутри сети, т.е. до шейпера? К этому все и идет, но часть клиентов осталось на старом DHCP сервере(IP+MAC) и его не перенести он на маршрутизаторе, а маршрутизатор в свою очередь был шейпером. Маршрутизатор мы избавляем от функции шейпера. DHCP(Option82) есть внутри сети. Вообщем свои сложности. Как бы временное решение, пока всех не перенесем на новый. Изменено 4 февраля, 2013 пользователем saff1000 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 4 февраля, 2013 (изменено) · Жалоба Если решение временное, то предлагаю применить следующий патч. Фильтровать DHCP-трафик по IP-адресам (0.0.0.0 или 255.255.255.255) в данном случае не стоит, т.к. это будет мешать работе скрипта с нормальными адресами. --- a/sc Mon Feb 04 13:17:45 2013 -0800 +++ b/sc Mon Feb 04 13:54:23 2013 -0800 @@ -1344,6 +1344,13 @@ } } + $TC->("class add dev $dev parent 1: classid 1:fffe htb rate 20Mbit ceil 100Mbit"); + $TC->("qdisc add dev $dev parent 1:fffe handle fffe:0 pfifo limit 100"); + $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ". + "match udp dst 68 0xffff match ip protocol 0x11 0xff flowid 1:fffe"); + $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ". + "match udp dst 67 0xffff match ip protocol 0x11 0xff flowid 1:fffe"); + # block all other traffic $TC->( "filter add dev $dev parent 1:0 protocol ip pref $pref_default ". Изменено 4 февраля, 2013 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
saff1000 Опубликовано 5 февраля, 2013 · Жалоба photon, спасибо, все заработало. Еще один вопрос. Нужно ли при появлении новых IP в базе делать sc stop, sc start? Или можно обойтись sc sync. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 5 февраля, 2013 · Жалоба Достаточно sc sync. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
minderm Опубликовано 5 февраля, 2013 · Жалоба А если используется полисер, куда надо аналогичний кусок кода встатвить? И если не сложно черканите код, который будет аналогично маркированые в iptables пакеты пропускать без ограничений. Если решение временное, то предлагаю применить следующий патч. Фильтровать DHCP-трафик по IP-адресам (0.0.0.0 или 255.255.255.255) в данном случае не стоит, т.к. это будет мешать работе скрипта с нормальными адресами. --- a/sc Mon Feb 04 13:17:45 2013 -0800 +++ b/sc Mon Feb 04 13:54:23 2013 -0800 @@ -1344,6 +1344,13 @@ } } + $TC->("class add dev $dev parent 1: classid 1:fffe htb rate 20Mbit ceil 100Mbit"); + $TC->("qdisc add dev $dev parent 1:fffe handle fffe:0 pfifo limit 100"); + $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ". + "match udp dst 68 0xffff match ip protocol 0x11 0xff flowid 1:fffe"); + $TC->("filter add dev $dev protocol ip parent 1:0 prio 1 u32 ". + "match udp dst 67 0xffff match ip protocol 0x11 0xff flowid 1:fffe"); + # block all other traffic $TC->( "filter add dev $dev parent 1:0 protocol ip pref $pref_default ". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...