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

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

Парни, расскажите, а как правильно сэмулировать, скажем 2000 PPPoE сессий для тестирования нагрузки на роутер?

 

Мне ничего кроме 2000 VLAN + агрегирующий свитч не приходит на ум. Решал кто-то такую задачу?

Share this post


Link to post
Share on other sites

Dark_Angel

Если можно с одного мака, то вообще без проблем - вызвать pppd call config 2000 раз

Если нужно с разных маков в одном влане, то linux macvlan делает интерфейсы с различными маками (создаются через ip link). Пото вызывается pppd call config1, pppd call config2 и т.д. в configX указаны разные интерфейсы

Share this post


Link to post
Share on other sites

Ну PPPoE же Level 2, разве можно с одного мака наплодить больше одной сессии и пустить через неё трафик?

 

А вот macvlan это то что нужно, судя по всему.

Share this post


Link to post
Share on other sites

Ну PPPoE же Level 2, разве можно с одного мака наплодить больше одной сессии и пустить через неё трафик?

Да, можно, идентификация сессии идёт по "номеру", а не по маку (или по номеру+маку). Другое дело, что некоторые брасы не умеют поднимать 2 сессии с одним маком в рамках одного логического интерфейса(из-за аппаратных особенностей). С софтбрасами такого не должно быть

Edited by srg555

Share this post


Link to post
Share on other sites

То есть если мы коннектимся к линуксу, то стоковый pppoe-server сумеет отличить две сессии с одного мака и правильно слать через них трафик?

 

Ну и попутно вопрос по тестированию нагрузки. На сколько я понимаю, нужно поднимать 2000 iperf клиентов, или 2000 iperf серверов ( чтобы слать на разные dst ) и собственно генерить с них/на них трафик. Есть ли какой-то более простой способ загрузить 2000 сессиий?

Share this post


Link to post
Share on other sites

отличит

 

можно iperf-ом, можно ping-ом, bwping-ом, netcat, сотни разных способов. Если будете пингом, то надо будет ratelimit-ы убрать в ядре

Share this post


Link to post
Share on other sites

Отлично, но всё же 2000 инстансов чего бы то нибыло iperf, ping, etc. прийдется запускать.

 

Спасибо за ответы, буду тестировать. Просто боюсь, что для тестирования одного роутера, нужно будет собрать 2 таких же пакето-генератора.

Share this post


Link to post
Share on other sites

Вы же будете запускать 2000 pppd на клиент-машине. Точно также и трафик-генераторы запустите. Ну да, памяти нужно будет не 1G, но в нынешние времена RAM это не проблема

Share this post


Link to post
Share on other sites

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

 

Впрочем вскрытие покажет.

Share this post


Link to post
Share on other sites

вероятно, кроме поднятия pppd нужно еще какой-то трафик нагенерить?

Share this post


Link to post
Share on other sites

Dark_Angel

ну и в чём проблема? поднять 2000 сессий и нагенерить трафика - для этого хватит современного "игрового" компа без видеокарты. у вас в офисе одного барахло типа P4 с 1G RAM?

Share this post


Link to post
Share on other sites

Что-то я не уверен, что слабого компа хватит для 2000 процессов + генерации трафика, если это не 100 Мбит конечно.

 

Но путь понятен - буду эксперементировать.

Share this post


Link to post
Share on other sites

В итоге при поднятии 2х сессиий с одного мака, трафик идет только через первую сессию. Через второй интерфейс трафик идет и по счетчикам и по дампу, но, например ping`om не засчитывается. Коннекты тоже не устанавливаются.

 

С первой работает всё как надо. Если положить первую - пинг сразу проходит. Пингую с биндом на интерфейс локальный адрес PPPoE сервера.

 

Фаерволлов нет, машины подключены друг к другу напрямую.

 

Может надо где-то еще подкрутить PPPoE сервер?

 

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

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Возникает странная проблема. Делаю 100 интерфейсов, просписываю 100 правил и делаю 100 таблиц на которые ссылаются правила с одной записью - шлюз - PPPoE сервер через соответствующий ppp интерфейс. После чего на этот интерфейс навешивается iperf.

 

Буквально сразу после того как скрипт отработал - почти все таблицы на которые ссылаются правила становятся пустыми. Если добавить в них запись снова - через секунду она снова пустая. То есть правила на месте, но таблицы на которые они ссылаются - чистятся.

 

В логах пусто. Без iperf всё работает как надо - записи в таблицах не исчезают. На 10-ти интерфейсах всё работает как надо, ничего не пропадает.

 

Если повставлять задержку в цикл, т.е. когда iperf и новые интерфейсы появляются медленее, то после того как скрипт отпработал, в некоторых таблицах запись еще остается, но со временем ( около минуты ) пропадает тоже.

 

Я вообще не понимаю что это за полтергейст. Кто-то сталкивался?

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Решительно не понятно что делать. Уже и ядро менял и разные варианты пробовал. Только даешь нагрузку на интерфейсы - маршруты из таблиц пропадают. Напрямую зависит от нагрузки. Если сделать просто пинг на интерфейс, то всё работает. Если сделать примерно 500 пакетов в секунду тем же пингом, то больше 4х интерфейсов под нагрузкой система не переживает - пропадают маршруты.

 

Даже зацепиться не за что. Выходит, что вышеприведенным способом проверить нагрузку для PPPoE - нельзя.

 

UPD. Всё оказалось весьма прозаично, как всегда. Оказалось, что сесии рвались и сами восстанавливались pppd, поэтому шлюзы пропадали. У pppd такая проблема бывает из-за неправильного MTU. Хотя MTU и был 1400 это всеравно вызывало проблемы. Поставил 1300 - проблема ушла.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Возникла другая проблема: при генерации трафика на PPPoE сервере - все пакеты попадают в одну очередь. В принципе логично: MAC, IP, VLAN, src port и другие хедеры пакета одинаковы. Не совсем понятно что делать. Что посоветуете?

 

Драйвер ixgbe-3.21.2.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Dark_Angel

сделать различные вланы - тривиально. просто сделать несколько сабов с разной dot1q encap, но не уверен что ixgbe умеет раскидывать vlan-ы по очередям. mac source тоже тривиально сделать несколько. просто делаете на клиенте и/или сервере несколько macvlan интерфейсов и гоняете трафик по ним. проще на клиенте. но и про маки я не уверен, что ixgbe умеет их учитывать для раскидывания по очередям

Share this post


Link to post
Share on other sites

И Влан и мак входят в хеш пакета, так что если они будут разные всё заработает. Даже если пакеты генерировать, скажем, пингом, то они уже разбрасываются по очередям, т.к. внутрености пакета разные - часть внутреностей тоже входит в хеш. Но пингом генерировать миллионы пакетов не удобно - они банально выносят систему на генераторе из-за переключений контекста. Я нагенерил 0.6М и процессоры кончились. А через iperf я генерю 0.5М и упираюсь в одну очередь на PPPoE сервере.

 

А как можно сделать разный mac source на одном интерфейсе? Меня бы такое решение устроило. ВЛАНы делать не хочу, т.к. это внесет поправку на инкапуляцию и деинкапсуляцию пакетов.

Share this post


Link to post
Share on other sites

И Влан и мак входят в хеш пакета, так что если они будут разные всё заработает.

Кто вам такое сказал? src/dst IP и не более того, из-за этого грабли с очередями и на реальном трафике.

Share this post


Link to post
Share on other sites

Мне это сказал Datasheet по чипу. Более того там есть несколько политик у Flow Directora и для разных политик в хеш входит разное количество полей. Ни у одной политики нет в хеше только src/dst ip. Этих полей слишком мало. Минимум входят 4 поля. В данном случае я говорю о чипе 82599, но я уверен, что тот же 82579 хеширует схожим образом.

 

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

 

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

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

А как можно сделать разный mac source на одном интерфейсе?

 

собственно я уже написал, фича называется macvlan:

ip link add link eth0 dev eth1-m0 type macvlan

ip link add link eth0 dev eth1-m1 type macvlan

и т.д.

в системе появятся интерфейсы eth0-mX, не забудьте их апнуть

Share this post


Link to post
Share on other sites

Всё очень грустно на генераторе, даже без macvlan. Процессора хватает примерно на 0.5-0.6 Mpps. Остальное выносит pppoe, kworker ( переключение между задачами ), и iperf. Сделал всего 50 тяжелых сессий, чтобы слишком много процессов не было. 1.5M переключений контекста.

 

Судя по всему я не правильно готовлю pppoe клиент. Он же умеет работать в ядре? Потому что я зову его с плагином, получаю ответ, что плагин запустился, но судя по переключениям он таки в userspace. Что посоветуете?

 

Да, спасибо за macvlan - судя по всему то что надо. В тесте еще не проверял, т.к. описал выше.

 

Кстати, как вариант решения проблемы с macvlan - это поднять их на хосте дампере пакетов и на них поднять сервера iperf. Тогда не нужно будет извращаться и размазывать pppoe сессии по виртуальным интерфейсам на генераторе.

 

И чтобы 2 раза не вставать: если установить 1000 сессиий, без всякого трафика, они начинают сыпаться - отключаться, подключаться. Судя по логам сервер получает ConfReq и переподымает сессию. Причем делает это постоянно для разных сессий. На клиенте всё выглядит точно так же. Типа "оппа, ConfAck", хотя я запрос не посылал. Возникает ситуация где-то на 900 сессиях. До этого, всё держится железно. Оба хоста имеют свободные ресурсы при этом.

 

То есть такое впечатление, что кто-то вставляет ConfReq пакеты в поток. На самом деле, мне кажется, что что-то не так с сервером и после определенного порога он начинает не правильно идентифицировать сессии по номеру.

 

UPD. Если сессии устанавливать медленно, то всё работает как надо. Видимо при работе с одним маком до того как выдается идентификатор сессии в неё можно нагадить. Решено вообщем. Осталась проблема описанная в самом начале.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

ну поставьте 2-3-10 серверов под клиенты, в чём проблема-то? вы же сервер тестируете на нагрузку, а не тормознутость клиента

 

вообще, способ есть, это ядерный pktgen, но он не умеет работать over ppp, поэтому вам нужно написать скрипт, который вытащит ppp session-id и слепить pppoe-пакеты и выпустить их в ethernet-интерфейс. будет работать с такой скоростью, что у вас сервер быстрее умрёт, чем клиент

Share this post


Link to post
Share on other sites

Я смотрел в сторону pktgen, но я для этого тестирования его использование вызывает больше вопросов, чем ответов. Для тестирования походу прийдется полностью реализовывать протокол pppoe ( хотябы на уровне сборки пакета ), а тем временем, например 2К сессий на клиенте уже делают 50% занятости CPU без всякой нагрузки.

 

Наставить клиентов проблематично. Я тестирую, например, на 2х процессорном Xeon ( 16 ядер ), который не дешевый. Он уже умирает, если дать ему 4К клиентских сессий. При этом на сервере нагрузку вообще не видно. Уже не говоря о том, что сейчас сервера соеденены напрямую, а для нескольких клиентов надо будет ставить свитч.

 

В идеале это клиент pppoe в kernel mode + iperf + macvlan чтобы всё по картам размазывалось. Умеет pppoe kernel mode в клиенте? Гугл рассказывает только про серверную часть в kernel mode.

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