ng_state - Полисинг и сервисные функции на FreeBSD

[shveitser]

NG_STATE

 

Модуль ng_state – это полисер с элементами DPI и возможностью классификации траффика и обработки траффика в зависимости от класса.

 

Примененене – ограничение полосы с учетом типа траффика. Например, при организации доступа в интернет.

 

Основные функциональные возможности:

 

 

• 
   
  
• Управление полосой (Rate Limit) абонентов
  
• Возможность назначения общей полосы на группу адресов
  
• Классификация траффика и возможность наложения политик на разные виды траффика
  
• Экспорт статистики в Netflow v5
  
• Возможность перенаправления WEB траффика для отображения сервисных сообщений
  
• Защита от флуда и аттак
  
• Обнаружение P2P траффика по поведению
   
  

 

 

Типичная схема применение модуля – в разрыве IP или ethernet траффика для управления сервисом абонентов.

 

Возможно примененеие модуля на существующем сервере.

 

При существенных объемах траффика– лучше выделить отдельный сервер и установить его в “разрыв”.

 

Модуль отдаленно реализует функционал обеспечиваемый устройствами типа Cisco SCE.

 

Полное описание тут

Ссылка

[Dyr]

Нифига ж себе накручено функционала. По описанию прям шоколад

[Ivan_83]

Какой профит от спихивания ng_car и ng_netflow в одну ноду?

 

Я плохо понял: зачем куча хуков на вход и куча на выход?

 

 

 

 

Подсмотрите в ng_tcpmss как не пересчитывать всю контрольную сумму, очень оригинально и работает. Если пакет направлен на этот же компьютер, то можно поиграться с ng_path для замены IP.

 

Куча закоменченых принтов и прочего закоменченого заменяется, обычно на конструкции вида:

 

#ifdef    NETGRAPH_DEBUG


#define DBG_PRINT printf

#else


#define DBG_PRINT

#endif

[apm]

Какой профит от спихивания ng_car и ng_netflow в одну ноду?

 

 

я так понял , тут не только ng_car

 

С помощью ng_car же не сделать аналог ipfw queue

[Deac]

я так понял , тут не только ng_car

 

С помощью ng_car же не сделать аналог ipfw queue

И здесь обещан rate limit и ничего более.

[shveitser]

Какой профит от спихивания ng_car и ng_netflow в одну ноду?

 

Я плохо понял: зачем куча хуков на вход и куча на выход?

 

 

 

Подсмотрите в ng_tcpmss как не пересчитывать всю контрольную сумму, очень оригинально и работает. Если пакет направлен на этот же компьютер, то можно поиграться с ng_path для замены IP.

 

Куча закоменченых принтов и прочего закоменченого заменяется, обычно на конструкции вида:

 

#ifdef    NETGRAPH_DEBUG


#define DBG_PRINT printf

#else


#define DBG_PRINT

#endif

Спасибо, tcpmcss посмотрю.

Про ifdef тоже спасибо, как правило принтфы использовались первый и последний раз при первозапуске и отладке и я скорее их удалю, если будут причины наводить эту чистоту

 

Куча хуков на выход - на выход попадает классифицированный траффик, чтобы делать что то разное с разными классами

[shveitser]

я так понял , тут не только ng_car

 

С помощью ng_car же не сделать аналог ipfw queue

И здесь обещан rate limit и ничего более.

Да, только limit-rate, код обрезки - из ng_car.

 

У меня встречный вопрос - в свое время мы проводили тесты и получилось, что для пользователя неотличим шейпер и полисер на скоростях выше 512 Мбит (вернее, он конечно, отличим при желании увидеть - это полисер или шейпер, но по работе программ и с точки зрения скорости загрузки страниц или работы качалок - разницы нет), до 512- из-за полисера возникают явные "пилы".

Сейчас тарифы уже далеко за 10мбит.

Так вот, вопрос - есть у вас какие то исследования или данные/опыт на эту тему, возможно, новые версии пользовательских ОС ведут себя по-другому? Было бы очень интересно. На наге есть тоже немного информарции на эту тему, она неявно подтверждает наши исследования.

 

Спасибо

 

Какой профит от спихивания ng_car и ng_netflow в одну ноду?

 

 

я так понял , тут не только ng_car

 

С помощью ng_car же не сделать аналог ipfw queue

 

Нет, очередей(shaping) здесь нет.

 

Я уже ответил на ниже, но мне все-же интересно - есть ли какой-то смысл в очередях? Можете, пожалуйста, поделиться опытом.

 

Спасибо.

[Deac]

Так вот, вопрос - есть у вас какие то исследования или данные/опыт на эту тему, возможно, новые версии пользовательских ОС ведут себя по-другому? Было бы очень интересно.

Есть.

Очереди, в инкарнации "GRED", при общей загрузке, подходящей к максимальной, оч. плавно всё раскидывают, незаметно для хомячков. Нужно только правильно подобрать параметры под каждый тариф. А учитывая, что максимальная загрузка наблюдается от силы 2..3 часа в день, лишних денег за полосу переплачивать особого желания нет.

 

Плюс к этому.

Несколько абонентов в одной выделенной полосе(случается не так уж редко), для GRED - не проблема, всё поделится; для полисинга - один забьёт остальных, без вариантов.

 

З.Ы. И там наверно 512Kbps, 512Mbps для хомячка жирновато.

Edited November 9, 2011 by Deac

[shveitser]

Так вот, вопрос - есть у вас какие то исследования или данные/опыт на эту тему, возможно, новые версии пользовательских ОС ведут себя по-другому? Было бы очень интересно.

Есть.

Очереди, в инкарнации "GRED", при общей загрузке, подходящей к максимальной, оч. плавно всё раскидывают, незаметно для хомячков. Нужно только правильно подобрать параметры под каждый тариф. А учитывая, что максимальная загрузка наблюдается от силы 2..3 часа в день, лишних денег за полосу переплачивать особого желания нет.

 

Плюс к этому.

Несколько абонентов в одной выделенной полосе(случается не так уж редко), для GRED - не проблема, всё поделится; для полисинга - один забьёт остальных, без вариантов.

 

З.Ы. И там наверно 512Kbps, 512Mbps для хомячка жирновато.

Да, конечно 512К.

 

Когда делали тесты, RED его варианты тестировали -еще раз повторюсь, после 512к нашли дискомфорт несущественным.Сейчас все тарифы выше 10Мбит, и загрузить все 10 неторрентом очень сложно, а торрент и в шейпере (традиционном) не даст адекватно работать.

 

Тем не менее, проделаю тесты еще раз.

Сделаю что-то типа MOS для VoIP для шейпинга и полисинга и разных полос.

 

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

 

Спасибо

Edited November 9, 2011 by shveitser

[littlesavage]

Вся обработка здесь на L2, от L3 решили полностью отказаться?

И цепляется оно напрямую к ng_ether - на входе ethernet пакеты, не IP?

 

Хотя, судя только по оформлению документации, штука очень мощная :)

[Ivan_83]

Вся обработка здесь на L2, от L3 решили полностью отказаться? И цепляется оно напрямую к ng_ether - на входе ethernet пакеты, не IP?

 

В том то и дело что нет. Внутри оно ищет IPv4 адрес и с ним работает. Цепляться напрямую к эзернету - единственный способ обработать трафик не пропуская его через сетевой стёк самой ОС.

 

 

 

 

Хотя, судя только по оформлению документации, штука очень мощная :)

 

Под капот лучше не смотреть :)

 

Хотя у коммерческих продуктов с закрытым кодом скорее всего так же.

 

 

 

 

 

[Ivan_83]

Куча хуков на выход - на выход попадает классифицированный траффик, чтобы делать что то разное с разными классами

 

Получается бесполезное дублирование пакетов по направлению к ноде.

 

Я для таких целей решил что лучше держать отдельные хуки in/out для каждого клиента, куда можно будет вешать ng_car или целые цепочки из нод, если хуки не подключены то гнать напрямую на up/down хук. Соответственно пакет пришедший на такой хук без обработки будет пересылаться на up/down хук.

 

Вообще, ноды очень лёгкие сами по себе и идеология у них как у гну: куча мелких утилит, каждая с простым функционал только для одной задачи, те особо разницы нет что поглотить ng_car внутрь своей ноды что подцепить отдельно, зато отлаживать легче.

 

 

[Deac]

Под капот лучше не смотреть :)

А и не надо, лишь бы ехала быстро и не ломалась. :)

[shveitser]

Куча хуков на выход - на выход попадает классифицированный траффик, чтобы делать что то разное с разными классами

 

Получается бесполезное дублирование пакетов по направлению к ноде.

 

Я для таких целей решил что лучше держать отдельные хуки in/out для каждого клиента, куда можно будет вешать ng_car или целые цепочки из нод, если хуки не подключены то гнать напрямую на up/down хук. Соответственно пакет пришедший на такой хук без обработки будет пересылаться на up/down хук.

 

Вообще, ноды очень лёгкие сами по себе и идеология у них как у гну: куча мелких утилит, каждая с простым функционал только для одной задачи, те особо разницы нет что поглотить ng_car внутрь своей ноды что подцепить отдельно, зато отлаживать легче.

 

Дублирования нет. OnetoMany настраиваются так, что траффик в направлении от ether, lagg и т.д идет через 1-ый хук (up1/down1). Остальные только для отправки траффика наружу.

 

Вы абсолютно правы, ноды действительно легкие и в первом варианте реализации, когда все настраивалось по принципу минимального вмешательства в код, был одна самописная нода которая обрастала тысячами NG_CAR. Суть этой ноды была- в зависимости от IP переключить в соответсвующий CAR, чтобы сделать полисинг.

 

Каких-то проблем это не вызывало, ни с количеством нод, ни с производительностью

 

Некрасивость такой схемы была в том, чтобы в другом месте также приходилось держать еще одну ноду, которая (гипотетически) отправляла траффик некоторых абонентов на проксирование в зависимости от IP и еще одну, которая (опять же гипотетически) отправляла траффик на детектор P2P опять в зависимости от IP, при этом куда было логичнее поиск делать один и совмещать его с поиском потока Netflow - поэтому хоть очень и не хотелось - оказалось эффективнее написать "вертолет", избавиться от лишних поисков, существенно упростить обвязку.

[shveitser]

Вся обработка здесь на L2, от L3 решили полностью отказаться? И цепляется оно напрямую к ng_ether - на входе ethernet пакеты, не IP?

 

В том то и дело что нет. Внутри оно ищет IPv4 адрес и с ним работает. Цепляться напрямую к эзернету - единственный способ обработать трафик не пропуская его через сетевой стёк самой ОС.

 

 

 

 

Хотя, судя только по оформлению документации, штука очень мощная :)

 

Под капот лучше не смотреть :)

 

Хотя у коммерческих продуктов с закрытым кодом скорее всего так же.

 

Спасибо.

 

Своих претензий к работе ng_state у нас нет.

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

 

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

 

Вот про шейпинг тема поднялась - очень хорошо, устрою еще тестирование. А то живу результатми 2008 года до сих пор.

[shveitser]

Под капот лучше не смотреть :)

А и не надо, лишь бы ехала быстро и не ломалась. :)

Едет она правдо быстро.

Насчет ломаться - нет - но я бы сказал так - "не ломается у нас", мы конечно, далеко не все варианты используем и думаю какими-то действиями можно модуль все-таки загнать в SEGV или блокировку.

 

Сегодня, кстати, запустили первую на 10G в продуктиве.

[shveitser]

Вся обработка здесь на L2, от L3 решили полностью отказаться?

И цепляется оно напрямую к ng_ether - на входе ethernet пакеты, не IP?

 

Хотя, судя только по оформлению документации, штука очень мощная :)

 

Точно так - траффик мы забираем с уровня L2 и далее модуль самостоятельно анализирует L3 и работает на его основе. Но на основе L3 делается только применение политик, маршрутизацией и прочим L3 модуль не занимается.

 

ОС этот траффик на L3 не обрабатывает.

[Giga-Byte]

авторам респект за проделаную работу.

[shveitser]

Так вот, вопрос - есть у вас какие то исследования или данные/опыт на эту тему, возможно, новые версии пользовательских ОС ведут себя по-другому? Было бы очень интересно.

Есть.

Очереди, в инкарнации "GRED", при общей загрузке, подходящей к максимальной, оч. плавно всё раскидывают, незаметно для хомячков. Нужно только правильно подобрать параметры под каждый тариф. А учитывая, что максимальная загрузка наблюдается от силы 2..3 часа в день, лишних денег за полосу переплачивать особого желания нет.

 

Плюс к этому.

Несколько абонентов в одной выделенной полосе(случается не так уж редко), для GRED - не проблема, всё поделится; для полисинга - один забьёт остальных, без вариантов.

 

З.Ы. И там наверно 512Kbps, 512Mbps для хомячка жирновато.

 

Сегодня провели тесты не механизм ограничения полосы еще раз.

Субъективные, объективно отрицательные последствия понятны.

 

Делали так - человек садился за чистую-эталонную машину и 4 раза тестировал User experience - занимался браузингом, закачкой, торренты и т.д.

Механизма ограничения и скорости человек не знал. По окончании теста ставил оценку.

Чтобы эффект от полисинга был более значительный, тестировали на скорстях в несколько раз меньше тарифных. (3-6Мбит).

 

Тестировавших было около 10.

 

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

Конечно по граффикам четко видны нюансы полисинга, но никто на это не жалуется.

 

При работающем торренете работать невозможно при обоих технологиях.

 

То есть, в целом, мы подтвердили свои результаты 3х годичной давности - на работу основных приложений полисинг не оказывает отрицательного влияния, заметного для пользователей (в основном http, его сейчас до 50%), отрицательное влияние уменьшается с ростом полосы.

 

Хотел бы задать вопрос-

Прошу прощения, но не понял - как можно за счет смены технологии нарезки полос сэкономить на внеших каналах (при условии сохранения тарифной полосы)?

 

Мое понимание такое - шейпинг, конечно, всплески проглатывает но только миллисекундные,но в целом, при 100% утилизации абонентом полосы экономии нет.

 

При большом количестве абонентов суммарные характеристики при шейпинге не будут отличатся от полисера за счет среднестатистичского усреднения. С увеличением количества разница будет все менее заметна.

 

Спасибо

Edited November 10, 2011 by shveitser

[shveitser]

Так вот, вопрос - есть у вас какие то исследования или данные/опыт на эту тему, возможно, новые версии пользовательских ОС ведут себя по-другому? Было бы очень интересно.

Есть.

Очереди, в инкарнации "GRED", при общей загрузке, подходящей к максимальной, оч. плавно всё раскидывают, незаметно для хомячков. Нужно только правильно подобрать параметры под каждый тариф. А учитывая, что максимальная загрузка наблюдается от силы 2..3 часа в день, лишних денег за полосу переплачивать особого желания нет.

 

Плюс к этому.

Несколько абонентов в одной выделенной полосе(случается не так уж редко), для GRED - не проблема, всё поделится; для полисинга - один забьёт остальных, без вариантов.

 

З.Ы. И там наверно 512Kbps, 512Mbps для хомячка жирновато.

 

Я хотел бы спросить - вы не сталкивались с механизмами "полисинга без дропов", возможно, используя какие-либо сообщения абонентким машинам. Кочено, вопрос про TCP только. Насколько помню, в стеке придусмотрен вариант Congestion - сигнализации.

 

Спасибо.

Edited November 10, 2011 by shveitser

[nuclearcat]

ECN, по нему и можно искать, оно не только для TCP, но далеко не все его понимают

[Deac]

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

Конечно по граффикам четко видны нюансы полисинга, но никто на это не жалуется.

 

При работающем торренете работать невозможно при обоих технологиях.

А если, всё же, попробовать вот так:

 

# Limits 1024Kbps
pipe 10 config bw 1060Kbits/s queue 60 mask src-ip 0xffffffff src-port 0x0000 gred 0.002/10/30/0.1
pipe 11 config bw 1060Kbits/s queue 60 mask dst-ip 0xffffffff dst-port 0x0000 gred 0.002/10/30/0.1

 

С учётом net.inet.ip.dummynet.io_fast=1

 

Не обязательно публичное тестирование, можно самому.

Edited November 10, 2011 by Deac

[Deac]

Хотел бы задать вопрос-

Прошу прощения, но не понял - как можно за счет смены технологии нарезки полос сэкономить на внеших каналах (при условии сохранения тарифной полосы)?

Это задача для общего шэйпинга.

Применительно к клиентскому - несколько точек в один тариф, встречается не так часто, но бывает.

[Ivan_83]

Вы абсолютно правы, ноды действительно легкие и в первом варианте реализации, когда все настраивалось по принципу минимального вмешательства в код, был одна самописная нода которая обрастала тысячами NG_CAR. Суть этой ноды была- в зависимости от IP переключить в соответсвующий CAR, чтобы сделать полисинг. Каких-то проблем это не вызывало, ни с количеством нод, ни с производительностью Некрасивость такой схемы была в том, чтобы в другом месте также приходилось держать еще одну ноду, которая (гипотетически) отправляла траффик некоторых абонентов на проксирование в зависимости от IP и еще одну, которая (опять же гипотетически) отправляла траффик на детектор P2P опять в зависимости от IP, при этом куда было логичнее поиск делать один и совмещать его с поиском потока Netflow - поэтому хоть очень и не хотелось - оказалось эффективнее написать "вертолет", избавиться от лишних поисков, существенно упростить обвязку.

 

Если у вас бпф делает весь детект, то можно результаты писать в:

 

m->m_flags &= M_VLANTAG;

 

m->m_pkthdr.ether_vtag = EVL_MAKETAG(vid, pcp, cfi);

 

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

 

 

[apm]

Автор, развиваете как то тему? Или все устраивает?