alexusss

Спасибо.

А в скриптах было реализовано как добавление, так и удаление? На железки в скриптах ходили по снмп или командами командной строки?

Здравствуйте! Присматриваемся к MA5608T. Планируем разворачивать схему Vlan per service. Из сервисов Интернет и IPTV - мультикаст. Интересуют следующие вопросы: 1. Есть ли проблемы с мультикастом на данном железе при большом количестве абонентов? 2. Пытался ли кто-то автоматизировать добавление/удаление ОНТ ? Спасибо.

Аналогичная проблема с отваливающимися мультикаст группами. ОЛТ (P3310C) подключено всего 2 ОНУ. К одной из ОНУ(P1004C1) подключена STB. Периодически перестает показывать канал. После некоторого кол-ва переподписок поток восстанавливается. Версия прошивки ОЛТ - Version 10.1.0E Build 36957

Здравствуйте! Подскажите какая версия софта на данный момент является стабильной для ОЛТ P3310C? Взяли на тест - там версия BDCOM P3310C Software, Version 10.1.0E Build 36039. Хотелось бы сразу тестировать актуальную стабильную версию. Спасибо.

Решена ли проблема с зависанием портов при массовой регистрации ОНТ на ОЛТ 3310С?

Присоединяюсь к вопросу. У кого есть успешный опыт реализации по данному вопросу?

Кто использует MX для терминирования pppoe? У циски есть замечательная команда ip tcp adjust-mss 1452 для пппое интерфейсов, которая решает почти все проблемы с фрагментацией пакетов. Для джунипера судя по ссылке ниже для этого необходимо иметь специальную MS плату. И при этом необходимо прогонять весь трафик через эту плату со всеми вытекающими отсюда последствиями и ограничениями(например плата MS-MIC-16G только 9G трафика пропустить). http://forums.junipe...480/td-p/229231 кто-то реализовывал это? если это так, то для пппое и л2тп это большая беда.

Кто использует MX для терминирования pppoe? У циски есть замечательная команда ip tcp adjust-mss 1452 для пппое интерфейсов, которая решает все проблемы с фрагментацией пакетов. Для джунипера судя по ссылке ниже для этого необходимо иметь специальную MS плату. И при этом необходимо прогонять весь трафик через эту плату со всеми вытекающими отсюда последствиями и ограничениями(например плата MS-MIC-16G только 9G трафика пропустить). http://forums.juniper.net/t5/Routing/how-to-change-tcp-mss-on-Juniper-MX480/td-p/229231 кто-то реализовывал это? если это так, то для пппое и л2тп это большая беда.

show policer | match arp __default_arp_policer__ 0 0 Нет. Забыл уточнить. у меня не IPoE, а PPPoE для кастомеров.

включен. настройки по-умолчанию. атаки не фиксирует. show ddos-protection protocols violations Packet types: 208, Currently violated: 0 Я склоняюсь к нехватке памяти и возможно сыроватому софту. Загрузка памяти 92%. Хотя идея с ддосом тоже имеет место быть, так как грузится именно control plane.

Ну и как производительность при этом? Много ли сожралось памяти? Как проц поживает? Тоже думаем переехать на 480-ый. На 80-м 4к максимум удается при наличии 2-х FV. При чем интересно то, что если убрать 1 FV - память не освобождается. П.С. Словили глюк тоже интересный при 4к и 2-х FV. В один прекрасный момент загрузка процессора скакнула на 50 процентов и держится постоянно. При чем процессор грузится прерываниями. При чем эта загрузка не зависит от кол-ва трафика или сессий. Думаю вылечится только ребутом. Кстати, может у кого то было и подскажет? Вот что грузит его: run show system processes extensive last pid: 57677; load averages: 3.29, 2.71, 3.00 up 22+02:30:59 00:06:47 155 processes: 6 running, 123 sleeping, 26 waiting Mem: 1401M Active, 116M Inact, 308M Wired, 117M Cache, 112M Buf, 41M Free Swap: 2821M Total, 2821M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 38 root 1 -36 -155 0K 16K WAIT 26.3H 34.13% swi3: ipopt ip6opt 10 root 1 171 52 0K 16K RUN 402.3H 29.00% idle 27 root 1 -68 -187 0K 16K RUN 342:52 4.98% irq36: tsec1 11 root 1 -40 -159 0K 16K WAIT 449:23 4.88% swi2: netisr 0 1142 root 1 123 0 15284K 8680K RUN 208:40 2.10% eventd 1457 root 1 4 0 497M 450M kqread 724:44 1.76% rpd 1534 root 1 99 0 286M 244M select 481:20 1.27% authd 1538 root 3 20 0 123M 79204K sigwai 332:21 1.03% jpppd 26 root 1 -68 -187 0K 16K WAIT 132:32 1.03% irq35: tsec1 1352 root 11 98 0 19672K 10140K ucond 892:43 0.98% clksyncd 1554 root 1 99 0 99M 58880K select 157:48 0.05% dfwd 1559 root 1 99 0 66408K 28328K select 147:45 0.05% dcd

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

Основная проблема STP - это реагирование на Topology Change, а именно сброс мак-адресной таблицы на ВСЕХ коммутаторах в MSTP region. Соответственно STP будет тем лучше работать, чем меньше свичей доступа находятся в одном MSTP region.