Jump to content
Калькуляторы

Эмуляция PPPoE сессий Как это сделать правильно?

судя по симтоман у вас относительно старое ядро, не умеющее нормально работать с большим кол-вом интерфейсов.

 

я на аналогичном xeon поднимал под 10к клиентских сессий обычным pppd на ядре 3.11. больше не пробовал ибо уперся в ram(там было совсем мало, что-то около 6-10Гб)

Share this post


Link to post
Share on other sites

Да, у меня 3.2.23, но токое же ядро у PPPoE сервера и ему нормально. Рекомендуете проапдейтится?

Share this post


Link to post
Share on other sites

Спасибо за линк. Рамы у меня 16 Гб должно хватить на 15-16К сессий. Для моего теста - этого достаточно. Попробую другие ядра. О результате отпишусь, может быть ядерный клиент и не нужен будет.

Share this post


Link to post
Share on other sites

Поменял ядро на генераторе ( 3.12.х ). Ситуация стала примерно в миллиард раз лучше.

Share this post


Link to post
Share on other sites

Dark_Angel

Надеюсь, что Вы опубликуете результаты. Мне тоже интересно ибо щас нет под рукой свободных high-end серверов :( только всякий хлам и виртуалки

Share this post


Link to post
Share on other sites

Ну а чего же с добрыми людьми не поделится?

 

Но с очередями по прежнему шляпа. Сделал macvlan на генераторе пакетов, назначил ИПшнички, то есть src_ip другой и маки другие. Всеравно всё сливается в одну очередь на роутере.

 

То что пакеты идут с разных маков видно на интерфейсе роутера.

 

Это iperf. Пинг по прежнему отжирает слишком много ресурсов, но пакеты по очередям размзывает даже без всяких macvlan.

 

Пока не понятно что делать.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Т.е. у вас ICMPoIPoPPPoE размызываются по очередям, а UDP/TCPoIPoPPPoE нет?

Share this post


Link to post
Share on other sites

Да, но тут нужно понимать еще, что пинг генерит разные пакеты внутри, а iperf скорее всего одинаковые.

 

Ну и Flow Directory пофигу что внутри фрейма PPPoE - он берет заголовки только внешнего пакета. Соответственно в этой ситуации еще более не понятно почему ICMP нормальный, а UDP - нет.

 

Щас попробую еще TCP, но там потоком сложнее управлять.

 

UPD. У TCP тоже самое.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

у вас карточка поддерживает явное указние метода классификации по вх. очередям? (ethtool -n/-N, http://downloadmirror.intel.com/22919/eng/README.txt )

 

Ну и Flow Directory пофигу что внутри фрейма PPPoE - он берет заголовки только внешнего пакета.

 

может оно не проверяет, что между eth и ip вставлен ppp-заголовок, а просто отсчитывает номера байтов

Share this post


Link to post
Share on other sites

у вас карточка поддерживает явное указние метода классификации по вх. очередям? (ethtool -n/-N, http://downloadmirro.../eng/README.txt )

 

Умеет, включил, но ничего не дало. Потому что UDP ( а у нас же PPPoE фреймы ). Другие опции хеширования и вообще TCP фрагментацию не умеет, судя по доке.

 

может оно не проверяет, что между eth и ip вставлен ppp-заголовок, а просто отсчитывает номера байтов

 

Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма.

Share this post


Link to post
Share on other sites

А явное задание mac->queue поддерживается у вас? flow-type ether src MAC m MAC_MASK action QUEUE_NUM

 

Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма.

tcp заголовок большой, поэтому можно пропатчить iperf, чтоб он вначало рандом/время/прочее засовывал, а запускать его в udp-режиме

Share this post


Link to post
Share on other sites

А явное задание mac->queue поддерживается у вас? flow-type ether src MAC m MAC_MASK action QUEUE_NUM

 

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

 

Считает по смещениям, поэтому то на что наткнется парсер карты - это будет именно заголовок ppp фрейма.

 

tcp заголовок большой, поэтому можно пропатчить iperf, чтоб он вначало рандом/время/прочее засовывал, а запускать его в udp-режиме

 

Вариант, но может оказаться, что проще будет собрать скрипт на pktgen, нежели патчить iperf. Вообще iperf меня удивил своей негибкостью. До этих экспериментов я думал, что если мне что-то надо будет поменять по скорости, то: вот он инструмент мечты, а по факту оказалось, что максимум что там можно крутить - это порт/хост у клиент/сервер, размер пакета и скорость. Чего для "глубокой аналитики" недостаточно, очевидно. Про user-space умолчим.

 

Я вот не уверен, что смогу нагенерить 1Mpps, ибо 500Kpps, уже дает 70% нагрузки на генераторе.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Почитал доку, мейл листы и это просто грусть какая-то. Карта может много, но драйвера за ней не успевают ( а иногда просто кривые ). В итоге я не один с такой проблемой. Как строиться хеш RSS рассказано красиво и с картинками в DS, вот только на практике пакеты в начале ( до 80-го байта ) отличаются, пусть и не на много. А RSS хеш получается у них одинаковый? Но судя по диаграмме распределения пакетов, во-первых очередь может определить ether type, во-вторых туннелированные пакеты у flow director`a в матчинге не учавствуют.

 

Но на всём этом фоне тогда не понятно как удается всё размазать пингу. Ведь туннелирование, хеш RSS и пр. - всё на месте.

 

По маку по очередям распихивать нельзя, умеет только L4. И то очень ограниченый.

 

Буду пробовать с ВЛАНами, т.к. тег - единственный доступный для распихивания по очередям инструмент, который по идее должен работать.

 

UPD. ВЛАНЫ не помогают. Пакеты тупо не попадают к Flow director. Видимо мне прямой путь в mails list.

 

UPD2. Если генерить TCP, то всё размазывается без Flow director по хешу RSS. Попробую что-то сделать через TCP.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Ну с tcp, вы, вероятно, всё равно в userspace упрётесь. Поскольку проблему с поднятием сессий решили, то теперь использовать pktgen для генерации трафика очень легко

 

Берёте псевдофайл /proc/net/pppoe:

# cat /proc/net/pppoe

Id Address Device

00008E07 00:11:22:33:44:55 eth0.33

 

Здесь 8e07 это ppp session-id(в обратном порядке, прямой порядок байт будет 0x078e (!)), 00:11:22:33:44:55 это мак-адрес браса(хотя вы и так его знаете), eth0.33 - устройство поверх которого поднята сессия. Собственно всё, вам больше ничего не надо, чтоб самостоятельно сформировать pppoe-фрейм.

Единственно что неудобно, что в этом файле нет явной привязки к номеру тунеля(pppX), но в вашей задаче оно и не требуется

 

А чтоб на сервере трафик размызывался по CPU, просто загоняете ICMPoIPv4 в payload, чтоб не эмулировать tcp

Share this post


Link to post
Share on other sites

Ну с tcp, вы, вероятно, всё равно в userspace упрётесь. Поскольку проблему с поднятием сессий решили, то теперь использовать pktgen для генерации трафика очень легко

 

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

 

Сейчас буду смотреть в сторону pktgen. Может заодно и ВЛАНы будут не нужны.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Нашел вменяемый netperf. Абслютно та же проблема: трафик попадает в одну очередь. Написал в e1000-devel мейллист, но никто ничего не отвечает.

 

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

 

Ну да и важный момент: без PPPoE всё работает как надо.

 

UPD. Короче походу всё очень грустно для PPPoE и других видов туннелей: говорят, мол, прибивайте ВЛАНы через VF, тогда можно будет руками распихать разные ВЛАны в разные очереди. Что делать в продакшене с этим делом - не понятно. Всё что не IP - не рулится ни Flow director, ни 5-tuple filter, но зато должно рулиться RSS, в нем тунелированные соединения трактуются как IP пакеты. В хеш попадают Source IP и Destination IP из L2 заголовка.

 

Наверное надо поковырять как менять регистр MRQC, в котором можно задавать функции парсинга пакета. Судя по всему, пакет не парсится, а в этом случае RSS index = 0. При отсутствии других хешей, это скидывание пакета в 0 очередь.

 

Еще вариант - включить DCB и попробовать рулить QoS приоритетами в какую очередь совать пакет. Это правда даст возможность разрулить только 8 очередей. Ну и костыль, к тому же.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Выяснили, что RSS функция не отрабатывает потому что в PPPoE фрейме смещения SRC IP и DST IP другие, соответственно функция их не находит. Почему нельзя было сделать хеш по макам - мне, лично, не понятно.

 

Вообщем пока решения проблемы нет: парни говорят, что надо юзать VMDq и прибивать парсинг L2 к виртуальным функциям ( VF ), но во-первых, у меня это чудо не заводится, а во-вторых не понятно как быть с этим в продакшене, где вланов нет, а мак адресов десятки тысяч.

Share this post


Link to post
Share on other sites

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

 

Тесты гоняю netperf. Он тоже кривой, но там большая часть операций kernel-space засчет чего он умирает от csw намного медленее чем его братья по функциям. И документация у него не плохая.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this