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

Dark_Angel

Активный участник
  • Публикации

    368
  • Зарегистрирован

  • Посещение

Все публикации пользователя Dark_Angel


  1. Всё очень грустно на генераторе, даже без 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. Если сессии устанавливать медленно, то всё работает как надо. Видимо при работе с одним маком до того как выдается идентификатор сессии в неё можно нагадить. Решено вообщем. Осталась проблема описанная в самом начале.
  2. Мне это сказал Datasheet по чипу. Более того там есть несколько политик у Flow Directora и для разных политик в хеш входит разное количество полей. Ни у одной политики нет в хеше только src/dst ip. Этих полей слишком мало. Минимум входят 4 поля. В данном случае я говорю о чипе 82599, но я уверен, что тот же 82579 хеширует схожим образом. Ну и тем более ни о каких проблемах на реальном трафике мне не известно, даже между двумя хостами, т.к. в хеш входит случайный кусок пакета. В подтверждение моих слов - распределяющийся трафик от пинга. Там пакеты внутри разные. В случае с генерацией трафика iperf - все пакеты как почти как близнецы, поэтому как хеш не строй - он будет одинаков. Но, возможно, я что-то упускаю из виду. Вот и решил уточнить.
  3. И Влан и мак входят в хеш пакета, так что если они будут разные всё заработает. Даже если пакеты генерировать, скажем, пингом, то они уже разбрасываются по очередям, т.к. внутрености пакета разные - часть внутреностей тоже входит в хеш. Но пингом генерировать миллионы пакетов не удобно - они банально выносят систему на генераторе из-за переключений контекста. Я нагенерил 0.6М и процессоры кончились. А через iperf я генерю 0.5М и упираюсь в одну очередь на PPPoE сервере. А как можно сделать разный mac source на одном интерфейсе? Меня бы такое решение устроило. ВЛАНы делать не хочу, т.к. это внесет поправку на инкапуляцию и деинкапсуляцию пакетов.
  4. Возникла другая проблема: при генерации трафика на PPPoE сервере - все пакеты попадают в одну очередь. В принципе логично: MAC, IP, VLAN, src port и другие хедеры пакета одинаковы. Не совсем понятно что делать. Что посоветуете? Драйвер ixgbe-3.21.2.
  5. Решительно не понятно что делать. Уже и ядро менял и разные варианты пробовал. Только даешь нагрузку на интерфейсы - маршруты из таблиц пропадают. Напрямую зависит от нагрузки. Если сделать просто пинг на интерфейс, то всё работает. Если сделать примерно 500 пакетов в секунду тем же пингом, то больше 4х интерфейсов под нагрузкой система не переживает - пропадают маршруты. Даже зацепиться не за что. Выходит, что вышеприведенным способом проверить нагрузку для PPPoE - нельзя. UPD. Всё оказалось весьма прозаично, как всегда. Оказалось, что сесии рвались и сами восстанавливались pppd, поэтому шлюзы пропадали. У pppd такая проблема бывает из-за неправильного MTU. Хотя MTU и был 1400 это всеравно вызывало проблемы. Поставил 1300 - проблема ушла.
  6. Возникает странная проблема. Делаю 100 интерфейсов, просписываю 100 правил и делаю 100 таблиц на которые ссылаются правила с одной записью - шлюз - PPPoE сервер через соответствующий ppp интерфейс. После чего на этот интерфейс навешивается iperf. Буквально сразу после того как скрипт отработал - почти все таблицы на которые ссылаются правила становятся пустыми. Если добавить в них запись снова - через секунду она снова пустая. То есть правила на месте, но таблицы на которые они ссылаются - чистятся. В логах пусто. Без iperf всё работает как надо - записи в таблицах не исчезают. На 10-ти интерфейсах всё работает как надо, ничего не пропадает. Если повставлять задержку в цикл, т.е. когда iperf и новые интерфейсы появляются медленее, то после того как скрипт отпработал, в некоторых таблицах запись еще остается, но со временем ( около минуты ) пропадает тоже. Я вообще не понимаю что это за полтергейст. Кто-то сталкивался?
  7. В итоге при поднятии 2х сессиий с одного мака, трафик идет только через первую сессию. Через второй интерфейс трафик идет и по счетчикам и по дампу, но, например ping`om не засчитывается. Коннекты тоже не устанавливаются. С первой работает всё как надо. Если положить первую - пинг сразу проходит. Пингую с биндом на интерфейс локальный адрес PPPoE сервера. Фаерволлов нет, машины подключены друг к другу напрямую. Может надо где-то еще подкрутить PPPoE сервер? UPD. Нужно для каждого интерфейса было создавать рул для маршрутизации по источнику.
  8. Что-то я не уверен, что слабого компа хватит для 2000 процессов + генерации трафика, если это не 100 Мбит конечно. Но путь понятен - буду эксперементировать.
  9. Согласен, просто боюсь, что на роутер нагрузка в результате будет меньше, чем на генератор, и соответственно чтобы такой роутер загрузить, нужно будет 2 генератора. Впрочем вскрытие покажет.
  10. Отлично, но всё же 2000 инстансов чего бы то нибыло iperf, ping, etc. прийдется запускать. Спасибо за ответы, буду тестировать. Просто боюсь, что для тестирования одного роутера, нужно будет собрать 2 таких же пакето-генератора.
  11. То есть если мы коннектимся к линуксу, то стоковый pppoe-server сумеет отличить две сессии с одного мака и правильно слать через них трафик? Ну и попутно вопрос по тестированию нагрузки. На сколько я понимаю, нужно поднимать 2000 iperf клиентов, или 2000 iperf серверов ( чтобы слать на разные dst ) и собственно генерить с них/на них трафик. Есть ли какой-то более простой способ загрузить 2000 сессиий?
  12. Ну PPPoE же Level 2, разве можно с одного мака наплодить больше одной сессии и пустить через неё трафик? А вот macvlan это то что нужно, судя по всему.
  13. Парни, расскажите, а как правильно сэмулировать, скажем 2000 PPPoE сессий для тестирования нагрузки на роутер? Мне ничего кроме 2000 VLAN + агрегирующий свитч не приходит на ум. Решал кто-то такую задачу?
  14. Разрешите встрять в ваш разбор: мне кажется, что дело в шейпере. Судя по перфу - классификатор вылез на второе место. Это не есть хорошо, "при хешах такого не было"(с). Ну и попробуйте следующую стратегию по диагностике проблемы: начинает тупить, начинайте отключать сервисами: шейпер, фаер. Полностью. И ждите минуту примерно, потому что как заметили верно ранее - машина накапливает снежный ком и чтобы выйти из состоянния softirq нужно какое-то время. То есть в ту же секунду может не полегчать. Если будет тупить на простом роутинге, то надо менять ядро. Потому что первый в топе у перфа - _raw_spin_lock - это код ядра, который и является в вашем случае бутилочным горлышком. А вот кто зовет этот код - это вопрос, который, кстати, можно снова таки профайлером посмотреть. У меня как-то такое было на супер-глючном 2.6.32 ядре, которое такое вытворяло на 1-2 Мбит/с трафика в при использовании IPSec. Но в моем случае по профайлеру сразу стало ясно откуда ноги растут. После смены на 3.2.23 - всё стало замечательно. Новым ядрам старше - я пока не верю. Там какое-то феерическое количество граблей для роутеров.
  15. Может быть кому-то пригодиться, но у меня проблема была в рамдиске. Ядро было собрано с CONFIG_DEBUG_INFO и рамдиск был размером 100 Мб. Именно поэтому после выбора опций на машине 2 система висела с минуту. Почему не загрузилась первая машина - для меня до сих пор загадка. После пересборки c CONFIG_DEBUG_INFO=n рам диск стал 15Мб и спокойно загрузился.
  16. И не забудьте отключить irqbalance. И если есть HyperThreading или другой вид виртуализации ядер - лучше сразу отключите.
  17. А можно как-то задебагать grub? У него, конечно, есть команда debug, но не из меню, ни в конфиге она ничего не дает. Пишет только, что Debug mode on.
  18. Да, настройки по дефолту у обоих серверов и сервера из одной партии.
  19. 2Ivan_83: Драйвера на контроллеры начинаются на рам диске, а до него еще дело не дошло. 2adnull: не мой случай - старт не холодный, висит именно в грубе и именно на определенной версии ядра. 2Hawk128: Вот похоже, да, только висит больше минуты и походу грузиться дальше не собирается. Может это баг загрузчика?
  20. Линукс тоже пишет, но дело в том, что вывод инфы о биосе начинается именно через минуту. То есть фактическая загрузка ядра начинается не сразу. Когда ядро уже начало грузиться - всё проходит очень быстро, там никаких задержек нет. Затык именно в стыке grub->kernel. В этом стыке черный экран.
  21. Да, но рядом такой же сервер из той же партии - всё ок. Сервера HP Proliant G7. Ну и кроме того: одно дело минутку повисеть, а другое дело 5 минут и тишина. Не должно же так быть. Кроме того, что, другое ядро ( ванильное ) быстрее, чтоли, оборудование инициализирует? Кстати, а как вы узнали, что оборудование инициализируется? Экран же черный.
  22. Господа, интересная ситуация: есть две одинаковые машины, с одинаковыми системами ( CentOS 6.3 ). Решил я собрать ванильное ядро 3.2.23. Собрал в RPM. Поставил на машине 1, создал initramfs, прописался в grub. Пытаюсь загрузиться в это ядро - получаю черный экран, который вот так и висит. Я ждал 5 минут. Машина не зависает при этом. Взял эту же RPM - поставил на машину 2, всё сделал тоже самое - загружается. Единственное что, черное окно после выбора опции загрузки в grub висит примерно минуту, и только затем начинается загрузка ядра. Мне такие задержки не только не понятны, но и необъяснимы - что можно делать 1 минуту я не понимаю. Пути к образам ядра и рамдиска я проверил, из опций там только ro и root= остальные опции убрал. Кроме того, если ядро битое, обычно либо машина зависает, либо это явно написано - тут вообще ничего. Пробовал так же собрать родное ядро руками - собралось и загрузилось без проблем. То есть проблема именно с ванильным почему-то и почему-то только на одной машине. Кто-то сталкивался с таким?
  23. За АМД и Броадком не скажу, но на Интеле и 82576 должны пропихнуть до 800Кpps. Тут еще зависит от настроек ipt_netflow. На таком трафике ipt_netflow может скушать 10-15% от процессора.
  24. Ваш вопрос изначально не имеет ответа, потому что не понятно что вы собираетесь на нем роутить. И вообще, только роутить ли. Поэтому уточняйте что вы хотите делать и, возможно, будет возможность ответить на ваш вопрос. На тупом роутинге, с размером пакета 500-600 байт, вы забьете двухпортовую 82576 без проблем. За broadcom не скажу. Это примерно 800 Кpps во все стороны ( 4 Гбита ). Вот только это конь в вакууме.