KaYot

А чего только в линукс? Нигде ниче внятного не показывает, когда I/O на пределе. Может я неправильно выразился на счет 100%. Не согласен, при загрузке дисковым i/o растет показатель wait в том же топе. Ну а при тупой маршрутизации/бриджевании огромных потоков трафика будут загружены все шины, но собственно CPU свободен, что и покажет top.

200!

2500

Обоснуй, что TOP не показывает в linux?

Кайот, реально это с загрузкой 100%, просто не учитывается в статистике. Да и гигабиты не интересны, pps больше скажут о реальном овэрхэде. А так интеловские бенчмарки с DPDK куда интереснее цифры показывают (160 Mpps), как и с netmap кстати. http://forum.nag.ru/forum/index.php?showtopic=81814&hl=route-cache&st=0 Это реальный сервер с аккаунтингом и полисингом абонентов, даже не бридж как я выше писал. Местами вывод top проскакивает, реально загрузка пара процентов.

Ето значит что такое на FreeBSD не возможно? P.S. http://info.iet.unipi.it/~luigi/netmap/ Бррр. По ссылке - некий SDK для смелых, с графиком тупой отправки pktgen. Какое отношение ЭТО имеет к реальному трафику в 37G полисера-бриджа в linux? В подобных условиях на тестах vyatta какой-то celeron под socket 1566 легко заливал тестовые 40гбит упираясь в интерфейсы. Да-да, на том же НАге я смотрел про испытания этого netmap'a и попытки его куда-то припинать. Но это ведь чисто академический интерес, не правда ли?

Ну на НАГе ветка есть, 37гбит по-моему получили на обычном железе с БРАС(!!) функционалом(аккаунтинг+полисинг). С ровно нулевой загрузкой, дальше уперлись в пакетную скорость pci-e шины - при росте трафика появляются дропы. Про хоть что-то подобное в BSD я никогда не слышал.

Аааа так бсд маздай) 2xE5520 получается стоит?

Там шо, HT включен? А может еще и conntrack с фаерволом?

2000грн

Процессор класса e3-1270 v2, мать собственно говоря любая. Легко можно поместить в 1u. Многоголовые оптероны не нужны. На задачах тупой маршрутизации PPS и трафик упирается сугубо в эффективность контроллеров памяти и PCI-e, вот с этим у свежих xeon'ов полный порядок. У вас должна получиться околонулевая загрузка всех 4ех ядер при 10г сквозном(если туда всякие soft-flow, и NATы с шейперами не пихать конечно и минимально подтюнить linux).

Скоро будет год как продаете

Дык вы поделитесь волшебными мантрами, интересно же.

Тогда такой девайс стоил 60$+, а примотать изолентой свич к медику - 35-40

Ну а я вижу. 20 ip за натом будут работать шикарно, 5к как ты предлагаешь - практически не будут.

Простите, но это маразм. Невозможно приготовить 5к юзеров через 1 ip, так что бы это не воняло. Будет вонять, и очень сильно. В конце концов можно /24 у кого-то в аренду взять, нынче это услуга популярная. Ну а 5к / 255 = 20 человек на ip, совершенно беспроблемная цифра.

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

А чем медик и примотанный к нему скотчем 8ми портовый свич хуже? Цена 40$(для хороших девайсов) вместо 60, доступность в любом ларьке.

Нужды мониторинга - life с каким-то пакетом с сотней смс в день. Рассылка клиентам - корпоративный life, за недорого любой объем рассылают по списку номеров с помощью простого API.

Некрасиво. Логика и математика у вас только в одну сторону работают, для своих девайсов из 2.5гбит получилось 2 реального(логично), а для 1.25 классического - 0.8(не очень). у бдкома SFP-модуль 1G у нас SFP-модуль 2.5G отсюда и логика расчета Вообще-то любой "1G модуль" на самом деле 1.25гбит. Разве не так?

Некрасиво. Логика и математика у вас только в одну сторону работают, для своих девайсов из 2.5гбит получилось 2 реального(логично), а для 1.25 классического - 0.8(не очень).

1) В варианте с dhcp-сервером нет никаких костылей, сервер данные берет из базы, их туда биллинг заносит в онлайне. 2) Если юзер "втыкнет ноут" - в любом из вариантов ему выдастся его IP и все Авторизация то по порту/влану а не по железке юзера.

все это хорошо не спорю, только я считаю более правильно будет делать так билинг с радиусом -- насы, ip-unnumbered. зачем городить опцию 82 если влан на порт? представляю конфиг дхцп на 200 свичей . добавили юзера в билинг, кончилось бабло у юзера, и т.д. нужно каждый раз костылем формировать конфиг по новому, имхо это секас. и так понятно откуда запрос пришел благо акцел это умеет. С радиусом проще запрос в базу по имени интерфейса (считай тот же логин) и выдача акцелю ip и т.д. да и редирект тоже можно заюзать ATTRIBUTE L4-Redirect 242 integer Ты чего-то неправильно понял. opt82 начин

А что сложного в opt82? Можно любой dhcp-сервер заюзать умеющий работать с данной опцией. Мне 'классически' оказалось проще и удобнее. Сам аццель позволяет и более простые схемы делать, можно IP выдавать радиусом и не париться, почему нет. Пробовали, работает. У меня dhcp-сервер выдает клиентам одни адреса(из базы), клиентам-должникам другие(с заворотом на страничку дай денег), неклиентам третьи(с заворотом на страницу авторизации нового пользователя). После авторизации нового пользователя(вводит свой логин/пароль от личного кабинета) он автоматом прописывается в биллинге, через 2 минуты

Vlan-per-user, на свичах доступа типовые конфиги с вланами 1-50 и больше ничего. На агрегации эти вланы упаковываются в q-in-q(svlan дом, cvlan клиент) и отправляются на accel. На accel'e работает dhcp-relay, релеит запросы из всех вланов на выделенный dhcp-сервер и вставляет option82 в виде svlan.cvlan DHCP-сервер с того же нага, там perl-скрипт выкладывали работающий с БД. Биллинг заполняет таблицу для сервера в виде юзер-влан, сервер по номеру влана(а точнее по паре, юзер+дом) выдает IP.