Перейти к содержимому
Калькуляторы

sc: скрипт для управления Linux-шейпером

Возможно, этот вопрос уже подымался, если да, прошу прощения за дубликат.

Этот скрипт расчитан на шепйинг-полисинг исключительно на двух интерфейсах, in и out?

 

Что делать, если их больше, и они 802.1q vlan-ы,

ставить отдельный тазик на бордер с кваггой и отдельный на шейпер с этим скриптом?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Возможно, этот вопрос уже подымался, если да, прошу прощения за дубликат.

Этот скрипт расчитан на шепйинг-полисинг исключительно на двух интерфейсах, 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 будет к примеру гоняться без шейпера т.к локал , вобщем вариантов мносто милллион.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

могу предложить вариант с использованием 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

мы значительно увеличим производительность?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Лучше не смешивать шейпинг с intervlan routing и поставить отдельную машину как шейпирующий мост. Псевдоустройства становятся узким местом при скоростях более гигабита.

 

применением u32/ipset мы значительно увеличим производительность?

Я никогда не пользовался iptables marks для классификации, поэтому не знаю. Очевидно, что хэш-фильтры u32 -- это наиболее быстрый метод классификации. В случае u32 ipset не нужен. Он имеет смысл только при использовании фильтра flow, т.к. в этом случае нельзя блокировать IP-адреса средствами tc, все пакеты так или иначе проходят через фильтр.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Лучше не смешивать шейпинг с intervlan routing и поставить отдельную машину как шейпирующий мост. Псевдоустройства становятся узким местом при скоростях более гигабита.

 

Спасибо за совет, т.е. топология будет где-то такая

L3-свич агрегации -- Shaper (n x GE bond_in - n x GE bond_out) -- border (bgp)

 

Какая ориентировочная производительсность такой схемы - сколько гигабит вытянет - 3,5,7?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за совет, т.е. топология будет где-то такая

L3-свич агрегации -- Shaper (n x GE bond_in - n x GE bond_out) -- border (bgp)

 

Какая ориентировочная производительсность такой схемы - сколько гигабит вытянет - 3,5,7?

Теоретически, может вытянуть столько же, сколько способен маршрутизировать. Если есть желание, можно поэкспериментировать с сетевухами на 10 Гбит. Однако, больше двух гигабит мне видеть не приходилось. При количестве пользователей, которое способно потреблять >2 Гб/с, у людей уже достаточно денег на какие-то фирменные решения, вроде SCE 8000.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не совсем понял как заюзать патч и с какой версией , поясните , очень необходима возможность добавлять в один класс несколько ip . а вообще сразу бы сетками 127.0.0.0/8 (пример)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

не совсем понял как заюзать патч и с какой версией , поясните , очень необходима возможность добавлять в один класс несколько ip . а вообще сразу бы сетками 127.0.0.0/8 (пример)

Патч есть на предыдущей странице. Если с помощью программы patch он не накладывается на последнюю версию, то надо в редакторе найти строки, которые начинаются с "-", и заменить на строки, начинающиеся с "+". Добавлять подсети тоже можно, если дописать код, чтобы в базе хранились еще и маски. Сейчас реализован шейпинг для отдельных IP-адресов.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С несколькими IP на один класс слишком много проблем возникает, поэтому я не стал реализовывать эту схему.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Чтобы не подменялось, нужно в некоторых местах заменить $TC->("... replace ...") на $TC->("... add ...").

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, поднят bridge на двух интерфейсах, запускаю sc-1.3.5, все нормально шейпится, но DHCP пакетики перестают проходить, подскажите пожалуйста, куда копнуть. Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Правило, блокирующее весь трафик, для которого не созданы фильтры, создается в строках 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

Потом, если будет время, напишу правила в явном виде.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Потом, если будет время, напишу правила в явном виде.

Если вас не затруднит...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня возникла странная пролема в работе. Скачал новую версию 1.3.5, стал конфигуроровать. Но при запуске не содаются правила, отладка показала , что не доходит до вызова функции tc_sys. Сталкивался кто-нибудь с этим?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

minderm, а какие ошибки при этом, у меня все прошло гладко.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня возникла странная пролема в работе. Скачал новую версию 1.3.5, стал конфигуроровать. Но при запуске не содаются правила, отладка показала , что не доходит до вызова функции tc_sys. Сталкивался кто-нибудь с этим?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я почему-то сразу не подумал, а зачем вообще нужно через шейпирующий мост пропускать DHCP и прочий широковещательный трафик? Это неправильный дизайн сети. Почему бы просто не поставить DHCP-сервер внутри сети, т.е. до шейпера?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

При количестве пользователей, которое способно потреблять >2 Гб/с, у людей уже достаточно денег на какие-то фирменные решения, вроде SCE 8000.

 

Я бы сказал что порог приобретения для SCE 8000 начинается при 8-9 Гб/с потребления и то это достаточно больно ударяет по бюджету. А 2-3 Гб/с - это вообще-то еще объемы пионернетов, которым точно такое железо не по карману да и нет необходимости, потому что такой поток обрабатывается на паре тазиков, которые стоят вместе в 50-60 раз дешевле SCE 8000.

 

Рекламные слоганы манагеров Циско-продаванов просто убивают:

 

Решение SCE может позволить провайдерам услуг повысить свой доход на базе существующей инфраструктуры.

 

Так и хочется послать подальше с таким подходом.

 

Доход повышается напрямую и гарантированно только в двух случаях:

- рост абонентской базы (здесь SCE ни разу не поможет)

- ввод новых востребованных услуг (вопрос каких и при чем тут SCE?)

 

Есть еще один способ - рост тарифов, но покажите мне оператора, который на территории РФ поднимал тарифы стабильно и регулярно в течение последних 2-3 лет?

 

В данном случае (2-4 Гб/с аплинка) SCE - отличный способ просрать средства, которые можно было бы вложить с пользой.

Изменено пользователем replicant

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В данном случае (2-4 Гб/с аплинка) SCE - отличный способ просрать средства, которые можно было бы вложить с пользой.

Честно говоря, я тоже не являюсь сторонником такого подхода. Если есть возможность сделать open source-решение, которое работает не хуже и выполняет требуемые функции, то нет смысла тратить деньги на переоцененное железо. Иногда конторы ищут не сетевых инженеров, которые могут работать с чем угодно, а узких специалистов по Cisco. Такими проще управлять в силу большей взаимозаменяемости. Плюс к этому, фирменное оборудование -- это понты и предмет гордости.

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я почему-то сразу не подумал, а зачем вообще нужно через шейпирующий мост пропускать DHCP и прочий широковещательный трафик? Это неправильный дизайн сети. Почему бы просто не поставить DHCP-сервер внутри сети, т.е. до шейпера?

К этому все и идет, но часть клиентов осталось на старом DHCP сервере(IP+MAC) и его не перенести он на маршрутизаторе, а маршрутизатор в свою очередь был шейпером. Маршрутизатор мы избавляем от функции шейпера. DHCP(Option82) есть внутри сети. Вообщем свои сложности. Как бы временное решение, пока всех не перенесем на новый.

Изменено пользователем saff1000

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если решение временное, то предлагаю применить следующий патч. Фильтровать 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 ".

Изменено пользователем photon

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

photon, спасибо, все заработало. Еще один вопрос. Нужно ли при появлении новых IP в базе делать sc stop, sc start? Или можно обойтись sc sync.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А если используется полисер, куда надо аналогичний кусок кода встатвить? И если не сложно черканите код, который будет аналогично маркированые в 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 ".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.