heap

Посмотрел. В итоге то ли в силу криворукости, то ли в силу иных причин, вот результаты: 1. Для начала захотелось попробовать режим flow. Прочитав вместо документации, которой нет, коменты в конфиге, что оно работает только с маской 16 для одной подсети - записал для теста подсеть: 10.10.0.0/16. заинитил sc, создался ipset, фильтры и дисциплины. сделал sc add 10.10.1.2 10Mibit и получил все 100Мбит. Есть подозрение, что неверно понимаю логику этого самого flow. 2. Пошел в сторону u32. Первый возникший вопрос, на который пока не искал ответ чтением кода скрипта - а нельзя ли не дропать все лишнее, а только зашейпить нужное? Далее - добавил таки свой и внешний айпи сервера, померял спидтестом скорость. Вход обжался. Исход нет (если верно понял - в силу NAT, а на внешнем интерфейсе несколько иной айпи). Это из базового комплекта, полагаю забороть как-то можно. А вот на закуску осталась задача - трафик то хоть и не сильно, а порезан тематически следующим образом: на определенные направления (местный IX и т.д.) скорость не резать. На другие резать согласно тарифного плана для каждого айпи. Были ли попытки тулзой решить поставленные задачи?

Для этого сделай либо отдельный домен, либо отдельный порт и апачевским проксированием выставь нужный корень сайта или конкретную страницу :) Ну я в том смысле, что вероятно таки DNAT веселее. Или я не могу понять недостатка DNAT перед REDIRECT.

Хм. Разве АРУшкой на модуле управляет коммутатор? Возможно она сама все-таки уровнем сигнала рулит?

Собственно задача чуть более широка. С одной стороны давно не крутил в руках FreeBSD (хотя на самом деле это и не причина). С другой стороны вопрос распараллеливания обработки трафика. В Linux имел дело как с bonding и smp_affinity, так и с драйверами на кучу irq. Во FreeBSD такого крутить не приходилось, да и производительность порта вроде не уступает Фришной реализации. И как еще один не совсем весомый фактор холиварный - с Линуксом во многих ипостасиях варится приходится, с Фрей редко. Потому на Линуксе многие грабли, так сказать, уже проходили, а на Фре потенциально заново топтаться по граблям и искать решения. Вобщем, математически точного ответа и сам затрудняюсь дать. :) А про редирект - ну если один сервер, то да - вопросов нет. А вот если и серверов несколько, и страничку хотелось бы не просто хтмл типа "денек дай", а как часть основного сайта или полноценной страницы оплаты.

Было дело, не помню точно от чего зависящее, но Луиджи выслал обновления и проблема решилась. Если не ошибаюсь грабля всплывала только при включенном io_fast. Как бы извращение-извращением, но вот аналога по удобству пока не встречал, особенно при использовании динамических пайпов и таблиц. Вот теперь посмотрю предложенное решение, о котором ранее не слыхивал.

Доброго времени. Наступили на следующие грабли. Поднят 10Гбит (LR) линк между Extreme Summit x650 и D-Link DGS-3627G. Проработав не менее месяца вдруг линк пропал. Перегрузка DGS не помогла. Рефлектометр показывал на линии по обоим жилам в районе 6дБ. В итоге оказалось, что SFP+ в Extreme ни в одной жиле не выдает сигнала. Поменяли SFP+ на другую в том же порту. Появился и сигнал, и линк поднялся. Вставили старую в другой порт - также и сигнал на месте и линк поднялся. Какие могли быть подводные камни в данном процессе и как их можно в перспективе избежать? Никому не приходилось встречать подобного? Есть подозрение на АРУ - но очень сомнительно почему раньше не глюкавило.

Да, вот, видимо, ipset - то что требуется. Спасибо - давно о нем слышал, но руки не доходили прокурить. Тогда уж в топик еще есть вопрос - а нет ли еще адекватного варианта Линуксового, чтобы не городить dummynet, при этом не теряя в производительности. Исходное условие - абоненты имеют свой айпи и тариф, однако никакой зависимости между айпи и тарифом нет. Нужно ограничить скорость туда/обратно согласно тарифа, при этом обычный tc u32 классифаер, полагаю, очень быстро уложит систему на лопатки, а хеши вероятно не в тему. Или я не прав?

Доброго времени всем. Помогите разобраться в следующей теме. Стоит Linux-router, озадаченный транзитом абонентского трафика (IPoE) в интернет. Для шейпинга установлен порт ipfw+dummynet под Linux. Некоторую нехитрую фильтрацию и абонентов с серыми айпи реализует iptables+netfilter. Блокировние должников реализовано добавлением их в заданную таблицу ipfw, которая дропается. И вот настал момент расширить работу с должниками. А имеено реализовать не обычный drop, а любой запрос на 80 порт кинуть на другой хост, на котором абоненту будет сообщено, что он должник и пора бы заплатить. Однако функционал NAT в Linux из ipfw у меня не заработал, а в iptables нет удобных таблиц, куда затолкать должников для сей операции. А забивать в iptables тучу правил iptables DNAT не очень оптимально и красиво. Какие есть варианты обойти и решить данную задачу? Возможно я чего либо не учел или не знаю. Заранее спасибо за любый светлые мысли. :)

Можно с этого места поподробнее? По-возможности может личка или ICQ, чтобы не флудить? Да, плата 6704. Но вот в данном контексте в ее задачи будет в основном входить L2 коммутация, какие могут крыться подводные камни и при каких условиях готовится покупать на нее DFC модуль? Собственно 6708 была поначалу отодвинута в сторону ввиду того, что она с оверсубскрайбингом. Картинка с CFC/DFC нарисовалась немного позже, как тут уже писали сайт циски бедновато светит эту тему. То бишь инфо есть, вот только отрыть без целенаправленного поиска тяжеловато. Расчет исходил из того, что на шину у нее будут все честные 40 Гбит.

Извиняюсь за оффтоп, в скором времени самому предстоит крутить 10Г на данной железке. Есть маленький нюансы - плату буду крутить на 4 порта, где критический момент PPS (без DFC). Может кто подскажет - как можно общий PPS промониторить на железке при помощи SNMP? Тот, который показывает команда: show platform hardware capacity forwarding

Есть несколько скользкий и холиварный вопрос, который бы хотелось обсудить со всеми желающими. Ставим задачу построить софтовый роутер. Даже скорее не роутер, а NAS. Основные задачи: терминация PPTP/PPPoE, ограничения трафика (полосы), трансляция адресов (SNAT), некий набор правил фильтрации. В качестве софта (хотя может быть в данном вопросе это не так важно) выберем OS Linux, accel-pptp/rp-pppoe (в ядерных режимах) и на последние две задачи netfilter/iptables. Откинем также вопрос о сетевых адаптерах - считаем, что это пригодный серверный Intel или Broadcom. Далее встает вопрос - чьи процессоры лучше справятся с поставленной задачей. AMD или Intel? В рассуждениях хотелось бы учесть архитектуру в целом - имеющиеся чипсеты и так далее. Кроме того сравнить хотелось бы в разных сегментах. Например, Core с каким-нибудь Phenom, а Xeon с Opteron.

Есть подозрение, что на самом деле не феншуй. Есть жалобы по типу "постоянно рвется связь", а с другой стороны видим - что если юзер рвет сессию, то в логе LCP terminated by peer, а тут вроде бы как и ошибка, а на самом деле в радиус приходит такой же самый User-Request.

Народ, если не затруднит - сделайте такие выборки из логов, куда пишет pptpd и pppd: grep -c "EOF or bad error reading ctrl packet length" <log file> и grep -c "couldn't read packet header" <log file> Вижу в логе сообщение по типу следующего: Feb 4 09:14:25 servname pptpd[29461]: CTRL: Client <client ip> control connection started Feb 4 09:14:25 servname pptpd[29461]: CTRL: Starting call (launching pppd, opening GRE) Feb 4 09:14:25 servname pppd[29462]: Plugin radius.so loaded. Feb 4 09:14:25 servname pppd[29462]: RADIUS plugin initialized. Feb 4 09:14:25 servname pppd[29462]: Plugin radattr.so loaded. Feb 4 09:14:25 servname pppd[29462]: RADATTR plugin initialized. Feb 4 09:14:25 servname pptp[29462]: Plugin pptp.so loaded. Feb 4 09:14:25 servname pptp[29462]: PPTP plugin version 0.8.4 compiled for pppd-2.4.5, linux-2.6.31.6 Feb 4 09:14:25 servname pptp[29462]: pppd 2.4.5 started by root, uid 0 Feb 4 09:14:25 servname pptp[29462]: Using interface ppp328 Feb 4 09:14:25 servname pptp[29462]: Connect: ppp328 <--> pptp (<client ip>) Feb 4 09:14:27 servname pptpd[29461]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! Feb 4 09:14:27 servname pptp[29462]: Cannot determine ethernet address for proxy ARP Feb 4 09:14:27 servname pptp[29462]: local IP address <server_ip> Feb 4 09:14:27 servname pptp[29462]: remote IP address <vpn_ip> Feb 4 10:53:25 servname pptpd[29461]: CTRL: EOF or bad error reading ctrl packet length. Feb 4 10:53:25 servname pptpd[29461]: CTRL: couldn't read packet header (exit) Feb 4 10:53:25 servname pptpd[29461]: CTRL: CTRL read failed Feb 4 10:53:25 servname pptpd[29461]: CTRL: Reaping child PPP[29462] Feb 4 10:53:25 servname pptpd[29461]: CTRL: Client pppd TERM sending Feb 4 10:53:25 servname pptpd[29461]: CTRL: Client pppd finish wait Feb 4 10:53:25 servname pptp[29462]: Terminating on signal 15 Feb 4 10:53:25 servname pptp[29462]: Connect time 99.0 minutes. Feb 4 10:53:25 servname pptp[29462]: Sent 34109808 bytes, received 3410500 bytes. Feb 4 10:53:31 servname pptp[29462]: Connection terminated. Feb 4 10:53:31 servname pptp[29462]: Modem hangup Feb 4 10:53:31 servname pptp[29462]: Exit. Feb 4 10:53:31 servname pptpd[29461]: CTRL: Client <client ip> control connection finished Feb 4 14:36:38 servname pptp[29904]: Sent 2388129462 bytes, received 67397518 bytes. Меня смущают вот эти строки: Feb 4 10:53:25 servname pptpd[29461]: CTRL: EOF or bad error reading ctrl packet length. Feb 4 10:53:25 servname pptpd[29461]: CTRL: couldn't read packet header (exit) Feb 4 10:53:25 servname pptpd[29461]: CTRL: CTRL read failed Feb 4 10:53:25 servname pptpd[29461]: CTRL: Reaping child PPP[29462] Feb 4 10:53:25 servname pptpd[29461]: CTRL: Client pppd TERM sending Feb 4 10:53:25 servname pptpd[29461]: CTRL: Client pppd finish wait После чего туннель падает, а в радиус приезжает Acct-Terminate-Cause = "User-Request". А ведь причина судя по всему в другом. Вопрос - в чем?

А можно поподробнее об известных в данном смысле проблемах для 36хх? Я, конечно, в курсе багов и приколов любой оборудки ДЛинк, но в другой ипостасии используются 36хх с OSPF как роутеры - вроде бы ничего пока не заметил массового. Было дело в более старой прошивке - глючил OSPF - но уже вроде бы пофиксили.

Это мысль. Спасибо. А какие железки L3 используете? Имеющийся под рукой 3627 от ДЛинка умеет не более 12к префиксов. Не то чтобы мало, но интересно у кого еще что есть :)

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

Всем доброго времени. Задался разрешением следующей задачи. По условию мы имеем некий граничный роутер, принимающий на борт два фулл вью. Под ним среди прочего обитает сервер доступа на базе Linux, который раздает интернет при помощи туннелей (PPTP, PPPoE). Основная масса абонентов имеет серый айпи и бегает сквозь НАТ. С другой стороны имеется группа абонентов, имеющих реальные(белые) айпи-адреса. На данный момент все выглядит просто и прозрачно - на граничнике указан статик роут в виде блока в стороны сервера с туннелями. Но ресурса одной железки в виде рутера скоро будет не хватать. Придется балансировать нагрузку между железками (2-3-4). При этом в ходе балансировки любой из абонентов со своим реальником можем появится на любой из раздающих железок. А значит нужно делать динамическую адресацию. На первый взгляд, видится все так. Между граничником и железками раздачи установлены OSPF или iBGP сессии, по которым производится redistribute local без агрегации. То бишь граничник будет получать десятки-сотни-тысячи роутов /32. Насколько сильно это нагрузит граничник? К слову - на месте граничника стоит не легкая железка Cisco 7606-S. Какие еще видятся варианты решения этой нелегкой задачи?

Судя по всему xeb пока откатит все это дело назад и будет заниматься иной реализацией, так как данная оказалась нежизнеспособной.

значит эксперимент не удался ... xeb, как насчет все-таки поступить следующим образом. Продолжить развивать эту идею, но заявить ее как девелопмент и организовать ее включение при сборке по ключу. По дефолту собирать вариацию со старым механизмом. Добровольцы обкатают новую возможность, возможно в итоге оно обкатается и будет очень полезно.

Я чего-то в этой жизни определенно не понимаю. До появления текущей версии балансировал нагрузку при помощи bonding. Нагрузка даже в пиках была на 6 из 8 ядер не более 50 процентов. С текущей доблестной версией совместно с bonding имеем странный пейзаж. Честно загружены все 8 ядер, но в далеко не пиковой нагрузке на 50-60%, в top вижу треды по два на каждое процессорное ядро pptp 30-35%, а по каждому CPU: нагрузка system 40-50%, в soft interrupt свои проценты по 20-30. В топ проскакивает регулярно на 100% нагруженный events или ksoftirqd. При этом в спидтесте у клиентов тоже довольно тоскливо все было. В итоге когда попытался всю эту историю остановить мы плавно вылетели в fixed recursive fault but reboot needed. Откатился на старую версию (0.8.4) - жизнь наладилась - два ядра практически в 0, остальные 6 10-20% и не выше и на спидтестах у клиентов все в норме. Откуда вопрос - есть ли мысли не тему, что послужило причиной подобного бесчинства, поддается ли это фиксингу и если нет - нельзя ли сделать подробный трединг опциональным (либо при сборке, либо при загрузке модуля)? Надо тредить - задал ключ, не надо - не задал.

А можно для тех кто в танке подробнее. Разнесли в потоки и избавились от локапов, но в фаере тоже дропаем. Значит я так понял была вероятность и других локапов, не зависимо от петель? Какого плана это были грабли?

Очень похоже на "классический" pptp, имхо. Accel должен масштабироваться почти линейно, и ЛА такого у него быть не может, он же в softirq. Ну дык он то в irq, а юзер-спейс процессам не хватает камня (тем же pppd) и они строятся в очередь подрисовывая LA.

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

Эм. Поподробнее - каким образом устроить туннель в туннеле? Какой из наиболее накуренных клиентов будет это проворачивать? Второй вопрос по посту с корбиной. То что сервер выдает какие-то косяки - это одна тема. Но как клиент может внести такую нестыковку, если pppd сам навешивает настройки (по радиусу или по файлам конфигурации).

А можно поподробнее - что имелось ввиду под петлей?