Перейти к содержимому
Калькуляторы

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на клиенте - обязательно, на сервере тоже, иначе медленно будет. http://forum.nag.ru/forum/index.php?showtopic=76343

 

дальше вы будете упираться в RAM

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Dark_Angel

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А явное задание 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% нагрузки на генераторе.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

 

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

 

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

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну с 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нашел вменяемый 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 очередей. Ну и костыль, к тому же.

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Изменено пользователем Dark_Angel

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.