[Navu]

На форуме все чаще и чаще поднимаются ветки о том, чем натить 1 гбит/с, чем шейпить 30 тыс пользователей, чем отфильтровать разные классы трафика, и особо острый вопрос - как получить netflow с хорошей точностью на потоках интернета от 1 гбит/с.

 

Полный текст новости

[survivor]

Отличная статья! Хорошо структурирована, хорошая детализация. Приятно отметить отсутствие лоббирования автором того или иного решения...

[Гость djonline]

Кирилл, поясни пожайлуста, во что упирается NAT в первом тесте при повышении до 100kpps, если загрузка CPU меньше 50% ? Из-за чего происходят потери ?

[cmhungry]

Кирилл, поясни пожайлуста, во что упирается NAT в первом тесте при повышении до 100kpps, если загрузка CPU меньше 50% ? Из-за чего происходят потери ?

На микротике - не видно. Мне кажется, он просто не успевает выбирать пакеты из очереди сетевой карты, пока лукапит пакет по нат-табличке. При переводе ната на stateless - снимаем и по 100кппс на HP DL140, хотя на stateful нате - 60кппс предел.

 

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

 

Гугль, кстати, идет по похожему пути - в стойках не мегаНАСы, мегасервера на 48 ядер - а обычный самосбор, но настраивающийся/меняющийся за 5 минут.

[Alex780]

+1 зачетная статья!

[shoorickello]

С микротиком всё проще - у него все задачи работают на одном ядре.

[cmhungry]

С микротиком всё проще - у него все задачи работают на одном ядре.

не согласен. МТ до определенной версии на HP DL160 осиливал 450мбит, с 3.13, что ли, стал тянуть 800 - и загрузка CPU упала.

[shoorickello]

Бодаюсь с их ТП уже давно - см. http://forum.nag.ru/forum/index.php?showto...st&p=438165

[Гость Serj]

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

[Гость RandallGraves]

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

[Гость vitek]

статья хороша, только всё-таки не ясно относительно PC nat'а, почему же пакеты теряются, может backlog маленький ? у нас сервер 2.00ГГц х 8 ядер упирался в пропускную способность интерфейса 1Gb/s и 160kpps, при загрузке процессоров в 45-50%, потерь пакетов не было. сейчас на нем как раз shaper-nat-netflow 110kpps-35% загрузки, 12000 пользователей. не совсем корректно сравнивать несравнимое :-). конфигурация той же cisco вполне определенная, а вот сервер можно собрать любой. интересней был бы ответ на вопрос: а можно ли сделать решение на сервере равное, например, модулю ACE и сравнить цены.

[cmhungry]

статья хороша, только всё-таки не ясно относительно PC nat'а, почему же пакеты теряются, может backlog маленький ? у нас сервер 2.00ГГц х 8 ядер упирался в пропускную способность интерфейса 1Gb/s и 160kpps, при загрузке процессоров в 45-50%, потерь пакетов не было. сейчас на нем как раз shaper-nat-netflow 110kpps-35% загрузки, 12000 пользователей. не совсем корректно сравнивать несравнимое :-). конфигурация той же cisco вполне определенная, а вот сервер можно собрать любой. интересней был бы ответ на вопрос: а можно ли сделать решение на сервере равное, например, модулю ACE и сравнить цены.

конфигурацию и настройки сервера в студию! =)

сетевые, операционка, настройки операционки (драйвера, HZ, на чем нат-шейпинг, sysctl)

 

 

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

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

[Гость vitek]

>> конфигурацию и настройки сервера в студию! =)

 

Ваш смайл поставлен очень правильно :)

поправлюсь, не правильно написал: не шейпинг,а полисинг. очереди накладно...

[Гость Оо]

как?! Явно ж не natd?

[cmhungry]

>> конфигурацию и настройки сервера в студию! =)

 

Ваш смайл поставлен очень правильно :)

поправлюсь, не правильно написал: не шейпинг,а полисинг. очереди накладно...

вот о честном шейпинге на PC я слышал про 800 мбит, на ipfw pipe

но - полоса выделялась неправильно

[jab]

 

даже комментировать нечего... ламеры-с...

[Falcor]

Статье +1.

Кстати насколько зависимы на цисках (7200 например) параметры трафик/туннели. Т.е. если будет на с7201 около 500 сессий, пропустит ли она 600-700Мбит или всё-равно 400 максимум?

[cmhungry]

Статье +1.

Кстати насколько зависимы на цисках (7200 например) параметры трафик/туннели. Т.е. если будет на с7201 около 500 сессий, пропустит ли она 600-700Мбит или всё-равно 400 максимум?

от PPS зависит очень сильно. И от используемого функционала (нат, шейп/рейтлимит, нетфлоу)

[chainick]

Спасибо за отличную статью. А почему обошли вниманием FWSM?

[photon]

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

Если навешать кучу задач на одну машину и делать неоптимальную классификацию (по правилу на каждый IP-адрес), то очевидно, что это приведет к массе проблем. Кроме того, я бы не судил о PC-шном железе по Микротикам с дохлыми CPU и сетевухами VIA и Realtek. Для сетевых задач обычно берутся чипы Intel и, возможно, Broadcom. Кстати, они же применяются и в ряде брендовых роутеров.

 

В случае использования pcq-очередей по адресным спискам в Linux на входе приходится маркировать (mangle) пакеты, а это достаточно процессороемкая операция.

PCQ -- это что вообще такое? В tc этого точно нет. Зачем что-то маркировать, да еще и на входе? Сдается мне, что авторы судят о подсистеме QoS в Linux исключительно по микротиковскому интерфейсу. Для шейпинга в Linux все нормальные люди используют дисциплину HTB и хэширующие фильтры. В плане FreeBSD не раскрыта тема динамических пайпов и pipe tablearg.

 

Статья хороша только как обзор рынка сетевого оборудования. Но серьезного, технически грамотного сравнения PC-based shaping bridge и аналогичных брендовых решений, скажем Cisco SCE, я в ней не увидел. И конечно, сравнивать PC-шники интереснее с SCE 1000 и 2000, а не с монстрами стоимостью по 110K$, вроде SCE 8000.

Изменено 11 декабря, 2009 пользователем photon

[cmhungry]

Спасибо за отличную статью. А почему обошли вниманием FWSM?

1. не удалось полапать

2. 256К сессий на нате - и не рвались лапать

 

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

Если навешать кучу задач на одну машину и делать неоптимальную классификацию (по правилу на каждый IP-адрес), то очевидно, что это приведет к массе проблем. Кроме того, я бы не судил о PC-шном железе по Микротикам с дохлыми CPU и сетевухами VIA и Realtek. Для сетевых задач обычно берутся чипы Intel и, возможно, Broadcom. Кстати, они же применяются и в ряде брендовых роутеров.

HP DL160 G5 - я бы не назвал "дохлым CPU с реалтеком на борту".

 

В случае использования pcq-очередей по адресным спискам в Linux на входе приходится маркировать (mangle) пакеты, а это достаточно процессороемкая операция.

PCQ -- это что вообще такое? В tc этого точно нет. Зачем что-то маркировать, да еще и на входе? Сдается мне, что авторы судят о подсистеме QoS в Linux исключительно по микротиковскому интерфейсу. Для шейпинга в Linux все нормальные люди используют дисциплину HTB и хэширующие фильтры. В плане FreeBSD не раскрыта тема динамических пайпов и pipe tablearg.

Раскрывать детально - смысла особого нет, это требует отдельной статьи. Как TC настраивать, как pipe/tablearg делать... как это менять из биллинга.

Насчет QoS в Linux да, согласен, что это мое "слабое место" - уже 2.5 года не шейпим на PC.

 

[MiB]

хорошо и полезно. +1

[TiFFolk]

Мне одному показалось, что netflow выпал из статьи, хотя четко прописан в заголовке?

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

 

Зато нет явной рекламы. Наверно мне эта статья понравилась больше чем предыдущие.

 

Но не думаю, что вы вложили много времени в эту статью. Просто расписали так, как у вас есть сейчас. Что, конечно, не уменьшает ценность данной обзорной статьи.

[Iva]

конфигурацию и настройки сервера в студию! =)

Сегодня NAT+шейп+аккаунтинг+нетфлов+фильтр на Supermicro сервере + сетевушке всего за 1200$ в сумме, упирается только в скорость сетевой карты 1G.

 

 

>uname -rms
Linux 2.6.30.9-96.fc11.2.iva.i686.PAE i686

>lsmod
Module                  Size  Used by
cls_u32                 6192  6
cls_fw                  4220  3
sch_sfq                 5280  4680
sch_htb                13080  6
imq                     4768  772
ipt_ULOG                8892  3
ipt_ACCOUNT             8604  4
xt_connlimit            3700  2
xt_multiport            2552  1
ipt_REDIRECT            2044  3
iptable_nat             5980  1
nf_nat                 17672  2 ipt_REDIRECT,iptable_nat
xt_DSCP                 2736  2
xt_IMQ                  1552  2
xt_comment              1272  4
ipt_set                 1732  16
xt_mark                 1496  14
xt_MARK                 1828  6
iptable_mangle          3344  1
ip_set_iphash           5208  8
ip_set_ipmap            3372  14
ip_set_nethash          5896  1
ip_set                 16028  7 ipt_set,ip_set_iphash,ip_set_ipmap,ip_set_nethash
igb                    75140  0

>cat /etc/sysctl.conf | grep netfilter
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_generic_timeout = 180
net.netfilter.nf_conntrack_icmp_timeout = 10
net.netfilter.nf_conntrack_tcp_timeout_established = 1800
net.netfilter.nf_conntrack_udp_timeout = 10
net.netfilter.nf_conntrack_udp_timeout_stream = 60
net.netfilter.nf_conntrack_tcp_be_liberal = 1

>cat /sys/module/nf_conntrack/parameters/hashsize
262144

>tc -s qdisc | grep sfq | wc -l
4680

>cat /proc/cpuinfo | grep name | uniq
model name      : Intel® Xeon® CPU           E5520  @ 2.27GHz

>free -o
            total       used       free     shared    buffers     cached
Mem:       2053888     564160    1489728          0     140720     208272
Swap:      2099192          0    2099192

Ограничение в 1G решается поднятием Bonding-интерфейсов. Пример без NATа, но он всё равно практически не влияет на загрузку CPU:

 

[Sonne]

Первая статья содержащее полезное знание, которое нельзя получить самому, покопавшись в оборудовании и документации. Было очень интересно почитать.