NAT + Shaper на Debian

[mirk]

Всем привет

 

Есть у нас связка из 2х Debian серверов. У каждого на борту по одному Xeon® CPU E31270 @ 3.40GHz

На первом делаем шейпинг трафика средствами tc. Второй сервер организует NAT.

Сервера сами по себе не особенно мощные но свою работу делают и пропускают до 3.6 Mbit/sec

 

Немного подробностей о шейпинге.

Для повышения производительности tc используем хеш таблицы и фильтры u32. т.е. Шейпинг происходит на основании src_ip пакета.

 

 

Мир не стоит на месте и у нас появился новый более производительный сервер. И захотели мы совместить задачи двух серверов в одном. Но тут появилась проблема. После объединения шейпинга и ната выяснилось что скорость "режется" только в одну сторону. Это происходит потому что ограничение работает только на исходящем интерфейсе, а пока пакет до него доходит происходит NAT и src_ip в заголовке меняется. Соответственно наши фильтры в tc перестают работать и скорость не "режется".

 

Вопрос к знатокам. Как можно победить проблему "одностороннего" ограничения скорости?

[vop]

Либо использовать виртуальный-интерфейс, либо маркировать трафик через iptables -j CLASSIFY

Edited May 20, 2015 by vop

[kayot]

Причем вирутальный - только IMQ, с IFB фокус не пройдет.

Вообще плохая это идея, совмещать шейпер и НАТ, ведущая к вечному геморою.

Как вариант - шейпинг заменить на полисинг и полисить на том же интерфейсе что и исход.

Edited May 20, 2015 by kayot

[NiTr0]

Причем вирутальный - только IMQ, с IFB фокус не пройдет.

 

С чего бы это? Пройдет. Натится на выходе, в IFB заворачивается на входе.

[kayot]

Не проходит. Заворачивается уже подмененный трафик.

[SABRE]

kayot, нет, NiTr0 имеет ввиду заворачивать с внутреннего интерфеса - там нет ната. Трафик WAN->LAN для внутреннего интерфеса исходящий, а LAN->WAN редиректить на IFB на внутреннем интерфесе.

Единственная ситуация, где нужен только IMQ, это когда нужно шейпить и трафик роутера.

Edited May 21, 2015 by SABRE

[kayot]

SABRE

Мда, это я еще прошлым тысячелетием живу, PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :)

Логично, ничто не мешает захватывать на локальном интерфейсе и делать что угодно.

[NiTr0]

, PPP-серверами где перехватывать трафик можно было только на внешнем интерфейсе, с НАТом :)

Элементарно на pppX перехватывается тоже, и заворачивается в ifb :)

[photon]

Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT.

[yakov2000]

у меня работает нормально на ifb

[911]

либо маркировать трафик через iptables -j CLASSIFY

насколько большая нагрузка будет/

Edited May 26, 2015 by 911

[photon]

насколько большая нагрузка будет/

Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables. В общем, не маемся херней с псевдоустройствами, а берем sc (http://sourceforge.net/projects/sc-tool/), ставим limit_method = hybrid, вешаем на внутренний интерфейс, и никаких проблем с NAT.

Edited May 26, 2015 by photon

[911]

photon

если бы еще сделали шейпер на несколько ип, цены бы вам не было! :)

[photon]

если бы еще сделали шейпер на несколько ип, цены бы вам не было! :)

Эта возможность доступна в платной версии.

Edited May 26, 2015 by photon

[vop]

Намного, т.к. хэш-фильтров нет, и каждый пакет будет проходить по куче правил iptables.

 

Ну если влепить все адреса в корневую цепочку, и совершенно забыть о "процедурной" структуре iptables, то да, будет долго ходить по одномерной цепочке. :) Хотя возможность вставлять несколько групп адресов в один класс не так уж и важна, по видимому. :)

Edited May 26, 2015 by vop

[911]

если бы еще сделали шейпер на несколько ип, цены бы вам не было! :)

 

Эта возможность доступна в платной версии.

 

а что почем?

[mirk]

да почем такой функционал ?

 

 

Решил попробовать сделать так, как предлагает photon

 

Проще всего повесить шейпер с полисером на внутренний интерфейс, где нет NAT.

 

Только у меня есть небольшая проблема с полисингом я не могу нигде найти пример как можно сделать полисинг для нескольких ip одного договора. В случае с шейпингом всё просто было использовал htb, а это классовая дисциплина, соответственно все ip договора заворачивал в один класс. Но с полисингом не получается классифицировать пакеты. Конечно можно просто разделить скорость договора на число ip договора, но это крайний вариант.

 

 

Если я не ошибаюсь photon является автором sc было бы интересно услышать мнение эксперта по вопросам tc

 

сам скрипт генератор у меня есть и мне не хватает только дописать полисинг под несколько ip

вот несколько команд которыми ограничиваю скорость на одном ip

 

 

tc filter add dev eth2 parent 1:0   prio 30 handle 2: protocol ip u32 divisor 256 
tc filter add dev eth2 parent ffff: prio 30 handle 2: protocol ip u32 divisor 256 
tc filter add dev eth2 protocol ip parent 1:0    prio 30 u32 ht 800:: match ip dst 192.168.222.0/24 hashkey mask 0x000000ff at 16 link 2: 
tc filter add dev eth2 protocol ip parent ffff:  prio 30 u32 ht 800:: match ip src 192.168.222.0/24 hashkey mask 0x000000ff at 12 link 2: 
tc filter add dev eth2 parent    1: protocol ip prio 30 u32 ht 2:c7 match ip dst 192.168.222.199 flowid 1:a03 
tc filter add dev eth2 parent ffff: protocol ip prio 30 u32 ht 2:c7 match ip src 192.168.222.199 police rate 4096000 burst 409600b drop flowid ffff: 
tc class add dev eth2 parent 1:1 classid 1:a03 htb rate 4096000 

Edited May 27, 2015 by mirk

[photon]

да почем такой функционал ?

Ответил в ПМ.

 

Только у меня есть небольшая проблема с полисингом я не могу нигде найти пример как можно сделать полисинг для нескольких ip одного договора. В случае с шейпингом всё просто было использовал htb, а это классовая дисциплина, соответственно все ip договора заворачивал в один класс. Но с полисингом не получается классифицировать пакеты. Конечно можно просто разделить скорость договора на число ip договора, но это крайний вариант.

Насколько я знаю, одним фильтром можно полисить подсеть адресов (если используются хэш-фильтры, маска должна быть больше /24), но не список IP из произвольных подсетей. Однако, если tc уже поддерживает логические операторы из серии "match ip src 192.168.1.1 or ip src 172.16.1.1", тогда можно и списком. Надо проверить.

 

Я бы раздал всем юзерам на upload по скорости договора, а на download будет шейпинг и деление общей полосы. Это же upload, его все равно будет мало.

Edited May 28, 2015 by photon

[photon]

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

[lacost]

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

 

По отдельности все работает как часы. Сейчас в качестве эксперимента хотим на более производительной железке (с 10Г картами) попробовать реализовать то же что сейчас реализовано по отдельности.

 

В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина.

[photon]

В принципе комбинируя полисинг и шейпинг удалось уложить все в одну корзину.... Но, при попытке нагрузить реальным трафиком - появился перекос по загрузке ядер. По одному ядру на каждом процессоре грузится в полку. Пока не знаем как решать. Вот тут в параллельной ветке (http://forum.nag.ru/forum/index.php?showtopic=104964) аналогичная картина.

Полисинг тоже на хэш-фильтрах сделан или нет?

[hsvt]

Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором?

[s.lobanov]

Господа, а желательно ли использовать сейчас Jumbo Frame между сервером с NAT и коммутатором?

 

в этом нет никакого смысла в типовых задачах

[mirk]

Вот тут http://forum.nag.ru/...howtopic=104964 для ровного распределения нагрузки рекомендуют сделать вот так

 

 

echo ffffff >/sys/class/net/eth0/queues/rx-0/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-1/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-2/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-3/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-4/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-5/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-6/rps_cpusecho ffffff >/sys/class/net/eth0/queues/rx-7/rps_cpus

 

 

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

 

И может кто нибудь скажет в двух словах, что именно делают эти магические команды

[Ivan_83]

Похоже что ffffff - битовая маска указывающая на каких ядрах проца выполнять конкретную очередь.

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