kisa

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

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

  • Посещение

Информация о kisa

  • Звание
    Студент
  • День рождения

Контакты

  • ICQ
    0

Посетители профиля

1 989 просмотров профиля
  1. задача - упростить установку, и мне очень хочется сделать это с минимальными затратами. т.к. сейчас все обкатано на gentoo, то, скорей всего, это и останется gentoo. у NPF очень много зависимостей, заного изучать процесс сборки мне не хочется.
  2. я собираюсь именно так и сделать , установка слишком сложная.
  3. Нет, не пугает. т.к. я уже сказал, что не собираюсь делать универсальный сетевой стэк на все случаи жизни, как это сделано в linux.
  4. NAT есть, он основан на NetBSD NPF - это аналог netfilter в части conntrack. полного функционала iproute, конечно же нет, но есть все самые базовые и нужные в первую очередь вещи. из tc есть только shaping. P.S. задачи копировать linux нет и не будет. Сейчас есть задача сделать BRAS с самыми базовыми вещами и производительностью, аналогичной железным решениям.
  5. Стоимость будет ниже аналогичных решений, возможно ниже в разы. >> Как будет лицензироваться? >> За что придётся платить возможным клиентам? Над деталями лицензирования думать рано. >> Какие существенные отличия от готовых бесплатных решений скорость Открытых работающих решений (dpdk или подобных, не ядерных) я не знаю. Если знаете, приведите ссылки. Всем будет очень интересно посмотреть.
  6. Меня спрашивают про какие-нибудь тесты. 1) есть тесты NAT. Подробно вот тут https://github.com/alexk99/the_router/blob/master/source_nat.md Если коротко, то с таблицей трансляций нат 1M (1 миллион), сервер с пятью ядрами, выделенными под рабочие потоки TheRouter, пропускает 5,4 Mpps( миллионов пакетов в секунду) - это примерно 40 гбит/c, если взять в расчет обычные пакеты большого размера. Processor: Intel(R) Core(TM) i7-5820K CPU @ 3.30GHz NIC: Intel X520-DA2 Ram: 32Gb 4x8 2) и есть тесты просто раутинга там железки были попроще Core i5, 3 ядра под рабочие потоки TheRouter'а, Суммарно (in+out) 14,8 Mpps 64 байтными пакетам. Количество ip потоков в трафике - 128k. Поток в этом тесте - это все пакеты с одинаковыми ip src, ip dst. Таблица маррутизации тоже 128k, фактически она могла быть любого размера, т.к. только количество потоков важно для таких тестов.
  7. мне понравился dpdk. хорошо документированных, качественных, бесплатных, с хорошим коммьюнити проектов я просто не нашел на тот момент. по поводу 100% - не совсем так. это не dpdk грузит, это большинство проектов на ранних стадиях разработки не реализуют стратегии энергосбережения, т.е. в основной цикл рабочих процессов не вставляют грубо говоря sleep. к диагностике это имеет косвенное отношение, можно смотреть на счетчики потерь, а наиболее "горячие" места в коде обычно смотрят профайлерами, тем же perf можно.
  8. Завершил разработку первой версии софтварного (dpdk) браса. Вот здесь https://github.com/alexk99/the_router/blob/master/bras/subsriber_management.md документация именно по функциям браса и howto https://github.com/alexk99/the_router/blob/master/bras/bras_howto.md с примером реализации небольшого bras сервера. Вот здесь документация по проекту https://github.com/alexk99/the_router, пример боевого внедрения в качестве bgp раутера https://github.com/alexk99/the_router/blob/master/bizin.md Текущая версия браса - это прототип, в нем нет некоторых фич, необходимых для боевой эксплуатации, таких как ipfix (netflow), nat algs (pptp, sip и т.п.). Но это может и не быть препятствием для построения полу-боевых тестовых систем. Проект не опенсорс, но бесплатный. Мне нужна помощь в тестировании, обратная связь и советы по фичам, которых сейчас не хватает больше всего. Если проект взлетит, то он будет платным. В таком случае все участвующие не останутся без лицензий.
  9. Очень вероятно в том, что trex не statefull генератор, а NAT в линуксе реализован на основе отслеживания состояния сессий (connection tracking) Т.е., например, чтобы стартанула nat сессия для обычного tcp соединения connection tracking механизм должен засечь SYN пакет, а trex их не шлет. Да и просто одного syn тоже будет недостаточно, нужен ответный syn-ack. Пробуйте warp17. В нем реализован tcp стэк и очень быстрый. Миллионы соедений, огромный pps. У меня тесты linux nat на ура прошли с его помощью.
  10. за распределение по очередям отвечает RSS. Для каждого пакета рассчитываешься хэш и в зависимости от его значения пакет попадает в нужную очередь. Хэш можно настроить так, чтобы он рассчитывался на основе только сетевого уровня (ip src, ip dst), а можно и включить учет портов. Никогда не настраивал рассчет RSS в линуксе, но вроде это можно сделать с помощью ethtool. Ключевое слово для ethtool rx-flow-hash.
  11. Потом, не очень понятно как будет себя вести connection tracking механизм netfilter'а. Ведь t-rex, насколько я знаю, stateless, т.е. он шлет просто пакеты и не умеет tcp/udp сессии. Поэтому, как будет вести себя netfilter, не будет ли он создавать "лишние" сессии? т.к. фактически нет tcp/udp, а есть просто пакеты, не связные друг с другом. Для тестов connection tracking'а, я бы взял warp17. он поддерживает tcp сессии и тоже дает огромную нагрузку в pps.
  12. А зачем hashsize 16 миллионов? Действительно столько будет сессий? В тесте у вас только 1M. Потом, ничего страшного если в бакете хеша будет две записи. А сколько t-rex выдает pps? какой размер пакета в тестах? ведь 10 гиг это может быть и 14Mpps и 2, в зависимости от размера пакета. t-rex dpdk тулза и лего выдаст почти любую скорость в пакетах. Т.е. я к тому, что он быстрее линукса c включенным conntrack как его не тюнь. Я бы начал с небольшого packet rate, постепенно его увеличивая до тех пор, пока принимающая сторона t-rex не начнет рапортавать, что пошли потери.
  13. Привет! Нужен интернет 100-200 мбит с берстом до гига, г. Казань, в районе ул. Комсомольская. Если есть другие точки в Казане, то тоже оставляйте контакты. В личку. Спасибо.
  14. Я тоже отказываюсь от редуктора, это решение класса костыльных, но только за деньги. И большинство ответов тех поддержки о пропусках: линукс - это не маршрутизатор, наверное, потери на вашем оборудовании и т.д. nfqfilter на другом ревизоре у меня дает лучше результаты.
  15. сегодня разговаривал с радио част. центром. У них в случае перенаправлений все наоборот, поле в графе "Адрес перенаправления" - это адрес, по которому шла изначальная проверка, а "Идентификатор (URL/domain/IP" в этом случае адрес редиректа. а с hashlimit'ом SYN уже кто-нибудь игрался? 10/s думаю будет нормально. тогда и dpi не будет пропускать лишний раз? ведь будь это обычный абонент, да я бы без разговору за такой флуд отключил, почему должны быть исключения?