melvin

Ничего не могу сказать плохого. Сам я такие эксперименты не проводил (включить все и сразу) Стараюсь на изначальном этапе руководствоваться все таки официальными рекомендациями. Если прокатывает, то ради Бога. Ведь в бензиновый автомобиль тоже можно залить дизельное топливо. Но при поломке я все таки предпочитаю искать причину ее возникновения, а не думать, что может быть солярка была плохой и возвращаться на один шаг назад. Если речь идет о нескольких головах на 4, 8 свистков, то может Вы и правы, но когда речь идет хотябы о двух 16 портовых головах, то эксперименты тэв этом случае не очень отобразятся на репутации.

Я прочел достаточно внимательно. Можно сне пояснить "изоляция портов, которая влияет на коммутацию"

Ограничения по таблице tcam действуют при подключениях dhcp-snooping, isg (ip source guard), dai (arp inspection), acl. Не влияют storm-control,. loopback Кол-во маков безусловно влияет на память, но при включении хотябы одной из перечисленных функций, режим апокалипсиса приблежается все ближе и ближе.

Да Вы очень сильно заблуждаетесь, ну очень сильно. Согласно Вашей теории, весь сетевой мир не должен работать, а интернета не должно существовать вообще. Рассмотрим ситуацию, когда есть менеджмент влан и некая мониторинговая ОС. Менеджмент сеть имеет влан 1 и сеточку 1.1.1.0/24, Сеть, которую нужно мониторить имеет влан 2 и 3 и сеточки 2.2.2.0/24 и 3.3.3.0/24 соответственно. Исходя из Ваших слов, чтобы мониторить сети в вланах 2 и 3, каждый влан необходимо заводить в мониторинговую ОС и с каждого влана и подсети нужно выделять один ip адрес. Таким образом, при 100 вланах в Вашей сети Вы получаете достаточно большие проблемы и самое главное, об экономии ресурсов системы уже ркчь идти не будет, так как Вы получите ежедневную борьбу человека и машины. Решение проблемы достаточно простое, если иметь нкбольшое, хотя бы, понимание в маршрутизации, а именно в самой простой его составляющей - статические маршруты. Таким образом получаем: На необходимое оборудование (где рулятся наши вланы 2 и 3 ) заводится менеджмент влан. На мониторинговой ОС находится только ОДИН менеджмент влан и только одна подсеть и ничего больше. На мониторинговой ОС, благодаря статическим маршрутом создаем следующее: 2.2.2.0/24 next-hop 1.1.1.2( айпи на той железке где рулятся вланы 2 и 3) через влан менеджмент 1. Таким образом, можно легко, к примеру, пингануть 2.2.2.2 в влане 2 с мониторинговой ОС в влане 1 с ип 1.1.1.1. В разрезе Вашего сообщения я так и не понял понятия "сегментация" относительно порт/влан. Не приследуется цель кого-то обидеть. Просто делюсь опытом. А вот олты включать каскадом - не самая лучшая идея. Ткамовская таблица не резиновая.

Версия тайгера не зависит от прошивки. Но, лучше, выложу, т.к. Bdcom - это еще те чудеса в коробке. Сам файл: tiger.blob

А меня одного удивил заявленный факт??? В первую очередь набирают пацанов на саппорт, а потом уже тим лида (ну, по христиански, руководителя тех. поддержки). А как же все работает тогда? И другая ситуация - саппортеры работают, заявлено топикстартером, и днем и ночью, а руководитель на фулл тайм??? Это как? Он, бедняга, сотрется от 24-х рабочего дня. Ну, правда, интересно.

Инетграция с juniper серии MX есть в планах (по аналогии с микротиком).?

ActiveX установлен?

Проблема решилась банально. Для начала - небольшое отступление. Удалось поковыряться в недрах интернета и проверить эксперементальным путем ограничения по кол-ву ONU на порту. Делаем вывод: Ограничения по таблице tcam действуют при подключениях dhcp-snooping, isg (ip source guard), dai (arp inspection), acl. На данный момент проблема решилась перепрошивкой на: BDCOM(tm) P3616-2TE Software, Version 10.1.0E Build 49510 Copyright by Shanghai Baud Data Communication CO. LTD. Compiled: 2018-1-11 15:4:51 by SYS, Image text-base: 0x10000 ROM: System Bootstrap, Version 0.4.5, Serial num:00315072970 System image file is "Switch.bin" hardware version:V1.0 (RISC) processor with 262144K bytes of memory, 32768K bytes of flash Base ethernet MAC Address: 00:e0:0f:5e:ee:ad PCB version:A snmp info: product_ID:2011 system_ID:1.3.6.1.4.1.3320.1.2011.0 Онушки на epon 0/7 теперь дальше продолжают регистрироваться и подтягивать конфиг с темплейта в автоматическом режиме. Таким образом ограничения не действуют на loopback и storm control - это факт. Благодарю форумчан, которые высказали свои идеи и предположения. "Поле для маневра" - это уже половина решения поставленной задачи. З.Ы: До этого была проблема с epon 0/6 (пол года назад), но решилась заменой SFP модуля. Но там ситуация была чуть другая, сигнал был хороший, но ни одна ONU не регистрировалась. Может кому поможет в будущем. После перепрошивки - конфиги не послетали (хоть и не должны были, но чем черт не шутит ). Все онушки зарегистрировались в штатном режиме, косяков со скоростью не обнаружено, ONU с порта на порт не плавают (бывает и такое ), вланы поподхватывали те, которые и были на них закреплены. На каждом epon порту действует access-list Для тех, кто ищет: BD_3616_10.1.0E_49510.bin

За совет спасибо. На ограничение по портам не похоже, т.к. на всех остальных портах от 58 онушек. Если есть ограничение по общей таблице, то достаточно, для эксперимента, вручную удалить несколько записей шторма с некоторых онушек. Перерегать онушки - не вариант. Несколько вланов и в этих вланах разные подсети. Спасибо.

Касается всех портов в целом при включенной функции или есть ограничение на общее кол-во ону с этим функционалом?

Как зачем????? 11 влан - это сервис под абонентов 44 влан - это менеджмент. Влан транком быть не может А что Вас возмутило в pvid ?????? э Да и смысл то не в том, куда Вы обратили свое внимание т.к. на всех остальных портах все замечательно. Ребят, а кто-то тестил 46085, как со стабильностью? ОООО, плюсую к карме.

Добрый день! Существует вот такая проблемка: На олте 15 pon портов (1-6,8-16) забиты практически полностью (по 3-4 свободных места на каждом). Темплейт тривиальный и один для всех epon портов: epon onu-config-template ep1 cmd-sequence 1 epon onu port 1 ctc vlan mode tag 11 cmd-sequence 2 epon onu port 1 ctc loopback detect cmd-sequence 3 epon onu port 1 storm-control mode 1 threshold 256 Настройки epon портов тоже одинаковы: epon pre-config-template ep1 binded-onu-llid 1-64 switchport trunk vlan-allowed 10-11,44 switchport mode trunk switchport pvid 44 ip access-group subs.filter switchport protected 1 Прошивка OLT'а: BDCOM(tm) P3616-2TE Software, Version 10.1.0E Build 36039 Copyright by Shanghai Baud Data Communication CO. LTD. Compiled: 2016-6-22 15:9:50 by SYS, Image text-base: 0x10000 ROM: System Bootstrap, Version 0.4.5, Serial num:00315072970 System image file is "Switch.bin" hardware version:V1.0 (RISC) processor with 262144K bytes of memory, 32768K bytes of flash Base ethernet MAC Address: 00:e0:0f:5e:ee:ad PCB version:A snmp info: product_ID:2011 system_ID:1.3.6.1.4.1.3320.1.2011.0 Описание проблемы: На 7-мом epon порту зарегистрировано 32 онушки, которые стабильно функционируют и выполняют свою задачу. 33-ая и последующие онушки, при добавлении, успешно регистрируются (reg горит стабильно, не пропадает), но конфиг теплейта не подтягивают ни в автоматическом режиме ни при конфигурации в ручную. Выдает следующее: Current configuration: ! interface EPON0/7:35 Но при этом в самом порту: epon bind-onu mac 8014.a8a4.1710 35 Замечено, что та же онушка, но на других epon портах регистрируется , подтягивает автоматом конфиг и нормально продолжает функционировать. - SFP модуль меняли; - ONU VSOL, BDCOM, FOXGATE - симптомы одни и те же. Заранее спасибо.

Слушайте, а может можно сделать так же как в других движках - каждый сам себе выбирает тему. Хочешь старую, хочешь новую и т.д.

Пробывал светить прожектором - результат ноль. Принял решение - наверное прожектор не добивает до конечной точки. Бугага

Очень интересует вопрос: А можно так опту слепить в одно целое и избавиться от херов*й тучи 10 Г модулей? И что будет если убрать промежуточные коммутаторы за хрен*ву тучу денег, которые выполняют функцию рипитеров, а просто в этот стык слепленных волокон подсветить 50 w led прожектором? (Или от led прожекторов дисперсия большая будет?)

ААААА, Верните назад.

День добрый! Кто-то использует платежную систему interkassa (interkassa.com) в своем юзерсайде?

так это про вас подрядчиков, которые работают наперегонки за корку хлеба Вы меня с кем-то путаете. Я к подрядчикам не имею никакого отношения.

так может тут не подрядчики виноваты, а заказчик долбойоб? ему же нравится планку опускать? ну так кто платит тот парадом и командует. Давайте все свалим на Папу Римского. У Шнура есть песенка со следующими словами, которые четко характеризуют реали: " Ведь если в башне по*бень, то хоть *бень хоть не *бень".

Это пипец. Слов просто нет. Ой Бл#, мой хороший товарищ работает начальником отделения у подрядчика Киевстара, но правда на обслуживании магистральной оптики. Но это все херня. К чему пишу, прекрасно знаю ситуацию, что подрядчики меняются с этакой эпизодичностью у КС, а почему? Да потому что Вы - уважаемые подрядчики, сначала без мыла в ж#пу залазите, да сцуко поглубже, путем демпинга, а потом думаете как найти именно того дебила, который захочет на Вас, уважаемые подрядчики, работать. Вы же тоже хотите денег заработать, правильно? На момент участия в тендере никто еще не задумывается о том, кто и что будет в дальнейшем делать. За годик - два существующий подрядчик понимает, что расходы у него растут, инфляция не стоит на месте и забивает хер на продление контракта с КС. Приходит новый подрядчик, естественно, еще понизив финансовую планку и при этом не подумав о своем будущем. Вот так и получается, вместо того, чтобы повысить планку, улучшить качество, собрать достойный коллектив, Вы - уважаемые подрядчики размениваетесь на копейку с 6 дневным рабочим графиком и сопуствующим пи*децом.

ІР зачем ? :-) лишние 30грн из кармана в месяц :-). Так и микрот тЫгда не нужен.

Скажем в Харькове или скажем через мобильного оператора?

Это капец, изврат так изврат. Ну да ладно. Для начала: 1) На обоих сторонах есть белый ip ? 2) Хоть на какой то стороне есть белый ip ?

.