NG_STATE
Модуль ng_state – это полисер с элементами DPI и возможностью классификации траффика и обработки траффика в зависимости от класса.
Примененене – ограничение полосы с учетом типа траффика. Например, при организации доступа в интернет.
Основные функциональные возможности:
- Управление полосой (Rate Limit) абонентов
- Возможность назначения общей полосы на группу адресов
- Классификация траффика и возможность наложения политик на разные виды траффика
- Экспорт статистики в Netflow v5
- Возможность перенаправления WEB траффика для отображения сервисных сообщений
- Защита от флуда и аттак
- Обнаружение P2P траффика по поведению
Типичная схема применение модуля – в разрыве IP или ethernet траффика для управления сервисом абонентов.
Возможно примененеие модуля на существующем сервере.
При существенных объемах траффика– лучше выделить отдельный сервер и установить его в “разрыв”.
Модуль реализует функционал обеспечиваемый устройствами типа Cisco SCE.
Что это такое / немного истории/ для кого это может быть интересно/экономика.
Немного экономики и здравого смысла.
Может быть интерестен при значительных объемах траффика для полисинга (>1Гбит), > 200 пользователей велико, отсутствии готового решения либо требуются функции, озвученные выше.
95% что это ISP, возможно, крупные шлюзы корпоративного траффика
Для пусконаладки и интеграции требуется время и знания в администрировании FreeBSD и сопряжения сетевых систем.
Я рекомендую устанавливать и эксплуатировать решения от Cisco или подобные, которые в силу своей “железности” и отлаженности дают гаранированный результат при наличии хорошей документации и поддержки.
Тем не меннее, если вы находитесь в ситуации как я – быстрый рост, сжатые сроки невозможность купить/ждать готовое решения, очень большое количество траффика для обрабоки, для вас не представляет затруднений настройка nix, вы хорошо знаете FreeBSD и есть опыт работы с netgraph – то этот модуль может вам быть выгоден.
Возможно, модуль будет интересен в случае, если в текущей инсnаляции уже стоит шлюз на базе FreeBSD.
Время
Портебуется около 40 человеко-часов на запуск и тестирование и еще 40 на доведения его обвязки до продуктива. Целиком пусконаладка займет месяц.
Железо
Стоимость платформы для обработки 4-5G дуплексного траффика составляет примерно 2000$, с 10G картой.
Платформа для обработки 10G в дуплексе обойдется в 3200-3700$.
История
Одна из составляющих работ ISP – нарезка полос абонентам. Исторически эта функция у нас была совмещена с NAS.
С появлением нового типа доступа, возникла необходимость резать скорости отдельным устройством, а также выполнять ряд сервисных функций – отсылать траффик на проксирование, показывать информационные сообщения, гибко управлять полосой P2P.
Наиболее подходящим устройством для этого казалось устройство Cisco SCE. Мы были готовы потратить в среднем 30к$ за каждый гигабит пропускаемого траффика и даже пожертвовать некоторыми функциями, и даже ждать по нескольку месяцев заказа, держа на складе 20-30% лишней емкости.
Устройство запросили на тест: прождали 2,5 месяца вместо обещанных двух недель. Получили, не понравилось - возможность прямого управления утсройством из собственного биллина отсутсвует, необходимо 3-4 отдельных машины для управления. Присланное на тест устройство не получилось запустить под нагрузкой (как потом выяснилось, один порт в нем был нерабочим). Время потрачено много, результата нет, бизнес и задачи ждут.
К моменту окончания тестирования мы уже эксплуатировали свое решение на полной емкости услуги на базе PC платформ, оно удовлетворяло нашим запросам, хоть и имело ряд претензий по функционалу и производительности.
Путь оптимизаций, поиска проблем, доработки функционала привел к разработке отдельного модуля, все недостатки/неоптимальносты были устранены.
Цифры
Количество пользователей - 65к.
Протестировано до 4млн одновременных потоков, что соответсвует примерно 5-7 Гбит. При среднем пользовательском траффик, тариф на одного пользователя 10-15 мбит.
Теоретически ограничением на количество потоков является ядерная память (3ГБ максимум). При выделении 2,5 гбайт под потоки получится запас в примерно 40-50 млн потоков, что достаточно для обработки примерно 50-70 гбит в дуплексе.
Цифры не являются финальными ограничениями и, вероятно, могут быть увеличены еще на порядок.
Производительность
Очень высокая, траффик обрабатывается на уровне ядра, при этом отсутсвуют накладные расходы на обработку пакетов фаерволом, обработку L3 и т.д.
Зависит от конкретных условий:
- от сетевых адаптеров,
- процессоров, количества ядер, частоты.
- характера траффика
- количество паттернов в классификации
Если в каждом направлении планируется обрабатывать более 500Мбит, то лучше всего использовать сетевые карты Intel с аппаратной обработкой траффика и несколькими очередями и многопоточные процессоры, меньшие нагрузки сможет переварить любое железо уровня Core2Duo и выше.
Пара примеров
При траффике 100к пакетов в секунду (примерно 600 мБит траффика) в каждую сторону на процессоре Core2Duo 6800 утилизациия примерно 55-60%.
Машина с процессором CoreI7-960 и Intel 10G адаптерами может обработать примерно 4-5 гигабит траффика в каждую сторону.
В случае, если классификация траффика, экспорт Netflow и перенаправления не требуется и основной задачей является только полисинг, то можно и нужно отключить Flow-Engine (пока это можно сделать правкой исходных кодов). Ориентировочно прирост производительности составит до 5 раз. В такой конфигурации 1 гигабит дуплексно на Core2Duo6800 пропускается с утилизацией около 15% каждого из ядер.
В данных примерах речь идет о среднем пользовательском интернет-траффике (40-50% http, 40% bittorrent).
Системные требования
ОС FreeBSD Ядро 8x. 2-4 Гб памяти, 64 битная ОС.
Инсталляция
Скопировать исходные коды. Собрать модуль, загрузить, собрать схему нетграф.
Схема включения
Пример 1. Отдельностоящая машина - с классификацией
Пример 2. Отдельностоящая машина - без классификации
Пример 3. Существующая машина
Пример 4. Организация резерва
Для резерва можно использовать включенный парралельно прямой линк “bypass” c завышенной стоимостью в STP/RSTP. Таким образом, при отсутсвии L2 связности через сервер траффик перейдет на bypass. Подобную схему можно реализовать и в рамках одного коммутатора, но на некоторых нужно отключить механизм обнаружения петель.
Примечание. Весь не-ip траффик проходит без ограничений по интерфейсам up1/down1 в обе стороны. Такой траффик также не попадает в полисер полосы по умолчанию. Таким образом все Link-State L2 протоколы будут прозрачно работать без ограничений (STP, RSTP).
Обратите внимание
Неразборчивый режим
Сетевые карты следует ввести в promisc когда работаем в “разрыве” чтобы отключить аппаратную фильтрацию траффика по мак,
Для всех интерфейсов:
ifconfig em0: promisc
Так как траффик обрабатывается в ядре
При критической загрузки машины она становится неуправляемой, так как не остается процессорного времени на обработку user-space приложений.
Фаервол IPFW
Траффик не доходит IP уровня ядра, а попадает в netgraph, ункционал фаервола для обработки транзитного L2 траффика сильно ограничен. Man ipfw.
MAC autorsrc для ng_ether
По умолчанию мак-адреса будут заменяться на мак-адреса сетевых карт, через которые проходит траффик. Чтобы оставить маки нетронутыми нужно отключить опцию autosrc в соответсвующих ng_ether
ngctl msg em0: setautosrc 0
Классификация
Модуль может получать информацию о классе траффика от внешних систем. Для классификации используется statefull предположение о траффике – то есть классификация производится по первым N пакетам в каждом потоке. После удачной классификации все пакеты в рамках потока классифицирауются тем же классом, без даьнейшей пересылки в классификатор.
Внешним классификатором может быть ng_bpf модуль или их цепочка. Возможности такой классификации
- tcpdump выражения
- длина пакета, заголовки
- паттерны с анализом содержимого пакета
После прохождления классификаци траффик отправляется в модуль обратно с пометкой класса.
Схема - пример каскадной классификации в ng_bpf
Что делать с классификацией ?
Модуль отправляет классфицированный траффик в направлении прохождения траффика с номером интерфейса, совпадающим с номером класса.
До удачной классификации траффик отправляется по интерфейсам с инедксом 1. (up1/down1)
Примеры обработки:
- послать в разные интерфейсы (например, можно отправить на интерфейс с прокси-сервером траффик на 80 порт)
- поставить дополнительный полисер на какой либо класс
- отправить P2P в медленный или дешевый канал
p2p
Определение p2p происходит по характеру траффика. Из определения исключается траффик, успешно прошедший классификацию. Определение траффика по характеру использует анализ веерности и интенсивности траффика. Каждые 5 секунд происходит расчет – использует ли клиент p2p. Если да – то следующие 5 секунд весь траффик p2p класса уходит из интерфейсов с индексом 2, если нет – то по умолчанию.
Защита от флуда
Не разрешается создавать более 4000 потоков на любой сервис, кроме сервиса по умолчанию. Таким образом отсекаются любые сканирования и пробы портов. Направленность сканирования значения не имеет.
Мы протестировали работу P2P и использовать более 4000 соединений в повседневной работе не удавалось. Типичное значение для 4-5 закачек в p2p– 300-500 соединений. При большом количестве закачек и тюнинге клиента P2P удавалось получить до 3000 соединенй.
Информационные сообщения
Позволяют отобразить сообщения, например сервисного или предупредлающего характера.
В WEB – траффике запросы на 80 порт отправляются на другой сервер ( меняется IP в заголовках ).
Управлене модулем
Для группировки нескольких IP адресов в одну группу, используется понятие “сервиса”. Сервис хранит единые политики и ограничения, которые применяются на все адреса, относящиеся к этому сервису. Пример – несколько компьютеров у одного абонента. Адреса присвоенные в один сервис делят одну общую полосу выделенную на этот сервис. Одновременно один адрес может входить только в один сервис. При смене сервиса адрес удаляется из предыдущего сервиса.
Основные сообщения, поддерживаемы модулем
Управление сервисом и адресами
ngctl msg ng_state: setservice { userid=”” ip=192.168.0.1 cir_up=200000 cir_down=200000 fwd=1 fwd_ip=192.168.0.5 p2pdetect=2 }
Задать параметры предоставляемого сервиса для абонента “
Если нужно с одним абонентом и сервисом ассоциировать много адресов – можно выполнить комманды
ngctl msg state: setservice { userid=”для каждого IP адреса.” ip=192.168.0.2 }
Fwd – перенаправить траффик на 80 порт на какой либо IP адрес (это подмена сайтов, используется для отображения каких-либо сообщений. Для проксирования использовать нельзя), отдельным параметром указывается IP сервера, на который будет отправлен траффик.
ngctl msg ng_state: getservice { userid=”” } ngctl msg ng_state: getservice { ip=192.168.0.1 }
Показывает текущие параметры сервиса для абонента “
Статистика
Покажет статитстику по пакетам и потокам, в том числе по отброшенным пакетам.ngctl msg state: servicestat { userid=”” } ngctl msg state: servicestat { ip=192.168.0.5 }
Обратная связь – сверка скоростей
ngctl msg state: getspeeds NДля сверки выставленных в модуле скоростей и скоростей в биллинге есть массовая обработка, возвращающая за один раз несколько скоростей, а именно столько, сколько влезает в 4 кб, начиная с пользователя N.
Описание хуков
upX, downX. X означает номер класса. Траффик, классифицированный как класс X будет выходить из интерфейса up если он идет вверх (интернет) или down (к пользователю) с номером X. Если такой хук не подключен, то up1/down1.
Существует также возможность установить флаг “обучения классу” на любом up/down. Например, установив командой
ngctl msg ng_state: setifupclass (iface=18 class=14)Весь траффик, входящий в up18 будет ассоциироваться с 14 классом. После получения пакета определенного класса поток маркируется этим классом и более не предпринимается попыток классифицировать пакеты в рамках одного потока. Пакеты 10 класса будут выходить из интерфейса down14.
Именно так устанавливаются классы для разных match правил bpf-классификатора.
newflows_up, newflows_down – интерфейсы, из которых выходят первые пакеты (до момента удачной классификации, но не более 10). Предполагается что пакеты проходят классификаторы и возвращаются через интерфейсы с установленным классом.
В случае, если класс остается неизвестным, следует установить класс потока в 10 (такой пакет не будет зациклен в классификатор, но следующий пакет в рамках потока опять попадет в классификацию). В случае любого другого класса номер класса будет ассоциирован с потоком и пакеты в таком потоке больше не будут классифицироваться.
Если классификация не смогла пройти удачно после 10 первых пакетов, то такому потоку присваивается класс 2 (возможный p2p траффик).
export – для экспорта netflow, работа хука 100% аналогичкна ng_netflow, предполагается использование ng_socket для отправки экспорта или локальное чтение через бибилиотеки netgrpah как из сокета.
Особенности управления сервисом, умолчания
“Сервис по умолчанию”:
Весь траффик, для которого не назначены сервисы и полосы проходит через “полосу по умолчанию”.
Задать параметры сервиса для такого траффика можно, пользуясь командой setservice без параметра userid для несуществующего в других сервисах адреса, например 127.0.02.
Чтобы узнать текущие параметры сервиса, необходимо выполнить коменду getservice для любого адреса, не входящего в уже присвоенные абонентам, например, для простоты можно использовать тот-же несуществующий адрес 127.0.0.2.
Установив размер полосы предельно малым, можно ограничить хождение траффика до тех адресов, которые не присвоены пользователям.
Netflow
Схема съема нетфлоу полностью аналогична схеме с ng_netflow.
Также в поле src_as приходит номер сервиса для потока. По номеру сервиса можно контроллировать корректность назначенного сервиса в УС.
Предопределенные классы
1 – класс по умолчанию, без ограничений
2 – возможный p2p траффик
10 – классификация невозможна
Скачать
тут
