nicolnx

Добрый день Подскажите, есть ли возможность заставить accel при работе с ipoe (L3/unclassified) не реагировать на пакеты предназначенные для самого браса? Только на транзитный трафик (по аналогии с lisg). Сейчас решил эту задачу выставив hooknum = NF_INET_FORWARD в ipoe.c, но не уверен насколько сие решение корректно Может быть, можно зааксептить input/output трафик правилами iptables до того как он попадет в хуки акселя? Также заметил небольшую странность при работе с forward default policy drop, - в правило -i ipoe+ -j ACCEPT пакеты влетают, а вот в -o ipoe+ - уже нет, приходится разрешать этот трафик с -o eth0 (интерфейс с которого инициируются сессии) - можно ли с этим что-то сделать? Спасибо

А в какой репозиторий, собственно, слать merge requests? https://sourceforge.net/p/accel-ppp/ ?

Коллеги, подскажите плз Если поднять accel с ipoe/l2 старт по dhcp то какой lease time лучше отдавать? Ведь если отдать, скажем, 2 часа то в случае ребута сервера клиенты потеряют связь в среднем на половину времени аренды?

а IGS поднимает на каждую сессию отдельный интерфейс с которого уже можно смело редистрибютить как и с любого другого? Если так то вопрос действительно решается проще некуда

то есть по сути все сводится к редистрибуции в IGP directly connected маршрутов к соотв. динамическим интерфейсам? Или я не так понял? ;)

> проблем быть не должно, особенно с маршрутами а можете ткнуть носом в документацию - никак не могу найти ничего на эту тему...

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

Добрый день Появилась мысль уйти от линуксовых брасов (IPoE) в сторону ASR (или стопки из 7301) с ISG Однако, останавливает следующий момент - хочется 2+ коробки (отказоустойчивость, распределение нагрузки, вот это все) Есть ли возможность при подъеме сессии на абонента создавать /32 маршрут на брасе (и прибивать его после падения этой самой сессии?) Нужно для того чтобы притянуть трафик абонента на тот брас который его в данный момент обслуживает Спасибо

на freebsd 10 инсталляция, похоже, сломана Downloading/unpacking noc-pkg-handlebars==1.0.0 (from -r etc/requirements/noc.txt (line 21)) http://cdn.nocproject.org/pkg/simple/ uses an insecure transport scheme (http). Consider using https if cdn.nocproject.org has it available Could not find any downloads that satisfy the requirement noc-pkg-handlebars==1.0.0 (from -r etc/requirements/noc.txt (line 21)) Some externally hosted files were ignored (use --allow-external noc-pkg-handlebars to allow). Cleaning up... No distributions at all found for noc-pkg-handlebars==1.0.0 (from -r etc/requirements/noc.txt (line 21)) Storing debug log for failure in /root/.pip/pip.log upgrade: 180: Cannot update python libraries Terminating

Если проблем с местом и питанием нет - я бы все же выбирал 6500 - там и резервирование питания, и высокая плотность портов, и перспективы на развитие. Если таковые есть - ну тут и думать-то нечего, коробка большая, шумная и по питанию кушает немало. По производительности тут все хорошо будет как на 35/37 так и на 6к, единственное что - если уже речь идет о доступе, то тот же самый sup2 в dhcp snooping не умеет (не знаю насколько вам это критично)

Если есть перспективы роста - 6500 вы сможете перенабить более новыми модулями. С 35/37 серией такого естественно не получится. > WS-X6148A-GE-TX У этих модулей оверсубскрайб 8:1 если что

Добрый Подскажите, есть ли возможность при релеинге DHCP на саб-влан supervlan'a поднимать /32 маршруты (как это делает cisco) ? Есть несколько сабжевых коммутаторов, хотелось бы приземлить на них влан на абонента и отдать один пул адресов, - не представляю себе как это можно сделать без этой фичи Спасибо

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

Мощность порядка 100-150 Вт

Резать через service-policy на SVI интерфейсе не вариант? + mlq qos vlan-based в конфиге порта У меня вроде как работает.

Есть одна площадка на которой нужно запитать несколько коммутаторов умеющих только 48 вольт. А на площадке кроме 220 ничего нет. Есть ли какое 1U решение этой проблемы? Желательно не за конских денег ;)

А какие изменения должен сделать провайдер Б ?

попробуйте добавить switchport nonegotiate дабы отключить DTP CDP тоже может ругаться, попробуйте на этих портах его отключить а так вообще switchport access ... не имеет абсолютно никакого смысла если стоит switchport mode trunk, 100%

> Есть такой интересный момент: как быть с резервированием Тоже непонятно. Вроде VRRP и заявлен, но толку с него при использовании CLIPS...

Засматриваемся на SE100, судя по доступным мануалам нам бы подошел Dynamic CLIPS, но тут вопрос - а что произойдет в случае перезагрузки браса? Не выкурят ли абоненты до истечения времени аренды DHCP? Или он привязки сохраняет у себя внутри где-то?

Да. Нативно под фрю (kqueue), под линухом тоже не сильно хуже (epoll). Может сразу на github да совместными усилиями допилим?

а на каких нагрузках?

Исходный код открывать планируете?

Добрый день Коллеги, подскажите пожалуйста, что выбрать для multicast -> unicast? OS роли не играет - могу поднять как на фре так и на линухе. Количество активных сессий будет измеряться сотнями. Судя по отзывам relaying лучше держит нагрузку, но несколько смущает закрытый код + он же не обновлялся довольно давно. С другой стороны натыкаюсь на инфу что в последних версиях udpxy стал весьма стабилен. Есть у кого реальный опыт борьбы с тем и другим?

Ну, пинговать control plane коммутатора таким пакетом я думаю идея не очень хорошая. Включите в каталист тестовый сервачок в один порт, ноут в другой и проверьте прямо на площадке. Ну а дальше уже по результату.. У нас эта коробка замечательно транзитит большие пинги (хотя и брезгует на них отвечать таким размером пакета)