ufm

Такие сопли, по хорошему, должен ловить loopdetect на самом OLT. Надо будет проверить, кстати. С другой стороны - в моей схеме это не страшно. Именно для этого у меня строгий traffic segmentation (он-же port isolation) включен во всей сети. С третьей стороны - удачные железки со стороны абонента могут порезать RSTP/STP пакеты или начать генерить свои приводя к всевозможным веселостям. Поэтому есть стандартное правило - на клиентских портах RSTP должно быть выключено и зафильтровано. От греха.

Вроде всё хорошо.

В прочем - без разницы. Оно _обязоно_ работать втакой схеме. А если нет - то это баг. Собственно оригинальное письмо - это багрепорт Владу. Я уже писал и говорил. Вы тратите время и электро-бумагу Исписали 3 страницы форума. А все для того что бы само удовлетвориться. Багрепорт на английском подробно пришлите мне или Андрею. Сюда вы зачем пишете? вам тут код поправят? Или думаете кто то стенд соберет, проверять будет??? А потом удивляетесь что с вами пререкаются. Ну что за наивность... Т.е. вот этого, того что я написал - мало? В ic-line писать надо лично и на английском? Прикольно.

Кольцо сделать мало. Надо что бы туда хороший пакет залетел, типа arp request.

Еще интересный вопрос - кто нибудь пользуется свичингом между ОНУ в пределах одной ветки (т.е. должно быть включено epon inner-onu-switch)? А то что-то у меня возникает подозрение, что и этот режим как-то замысловато работает.

Да я, честно говоря, подустал быть тестовым полигоном для BDCOM за свои-же деньги. Я ошибку нашёл? Нашёл. Пусть дальше китайцы разбираются. Иначе мне будет очень интересно послушать, чем они мотивируют то, что у них написано о поддержке 802.1Q в их оборудовании, а оборудование нифига этот стандарт не поддерживает.

Не, ну я всё допускаю, конечно. Но я повторюсь - оригнальное письмо это багрепорт Владу. Оно обязоно работать так, как я написал при данных настройках. И если не работает - это баг. И его надо исправлять.

Давайте мы не будем обсуждать то, в чем вы явно не разбираетесь? Ну если вам правдо интересно, я могу рассказать что это, зачем и как работает. Но это явно скорее для лички. А пока просто примите на веру - это рабоотает и так надо. Свичпорт протектед вырубить попробуй. Как впрочем и всю остальную сегментацию. facepalm.jpg Еще один. Вот скажи мне, какую мою проблему ты предлагаешь мне решить отключив сегментацию? Особенно с учетом того, что мне _нужна_ сегментация. Нет, мне, в данной схеме, не нужно что-бы трафик ходил между портами вобход "транслятора". Или ты думаешь я просто так включ

В прочем - без разницы. Оно _обязоно_ работать втакой схеме. А если нет - то это баг. Собственно оригинальное письмо - это багрепорт Владу.

Сейчас стенд разобран, если будет время завтра - соберу обратно. Впрочем, там по любому ничего экзотичного быть не должно. MAC первого компьютера должен быть виден на порту ONU в влане два, на гигабитном порту OLT в влане 3. На свиче - на первом порту в влане 2 и на третьем порту в влане 3. MAC второго компа - в зеркальном виде. При указанных настройках и ONU и OLT запрещен внутренний свитчинг, только через внешний роутер. Соответственно прохождение пакета со второго порта на первый: 1. Попадаем на ONU через второй порт в третьем влане. 2. Входим с ONU на OLT в влане 3. Видим dest mac

Честно говоря, я немного удивлён. Ребят, знание как ходят по L2 пакеты и как свичи отрабатывают VLAN-ы - это как-бы базовые наши знания, нет?

Сейчас стенд разобран, если будет время завтра - соберу обратно. Впрочем, там по любому ничего экзотичного быть не должно. MAC первого компьютера должен быть виден на порту ONU в влане два, на гигабитном порту OLT в влане 3. На свиче - на первом порту в влане 2 и на третьем порту в влане 3. MAC второго компа - в зеркальном виде. При указанных настройках и ONU и OLT запрещен внутренний свитчинг, только через внешний роутер. Соответственно прохождение пакета со второго порта на первый: 1. Попадаем на ONU через второй порт в третьем влане. 2. Входим с ONU на OLT в влане 3. Видим dest mac

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

Проблема с прохождением unicast пакетов. Стенд: ONU 1004 с прошивкой 1104/1106/1107/1114 - 1 штука OLT P3310B с прошивкой 10.1.0B Build 12547 - 1 штука любой свич с поддержкой VLAN - 1 штука компьютеры - 2 штуки Патчкорды всех мастей - по потребностям. Собираем стенд: ONU втыкаем в OLT и настраиваем так: interface EPON0/1:1 onu-configuration epon sla upstream pir 1000000 cir 512 epon sla downstream pir 1000000 cir 512 epon onu port 1 ctc vlan mode tag 2 epon onu port 2 ctc vlan mode tag 3 no epon onu spanning-tree epon onu port 1 loopback detect epon onu port 1 storm-control

А вот фиг. Всё равно arp ходят через раз. А вот фиг - они вобще не ходят. Кто нибудь - можете подтвердить данную проблему?

А вот фиг. Всё равно arp ходят через раз.

Китайцы жгут напалмом. Следующая конфигурация: ONU1: interface EPON0/1:1 epon onu port 1 ctc vlan mode tag 2 ONU2: interface EPON0/1:2 epon onu port 1 ctc vlan mode tag 3 OLT включена в свич. В этот-же свич включен vlan транслятор, который всё что приходит в vlan2 отправляет в vlan3 и наоборот. Теоретически всё должно работать, и железка включенная в ONU1 должна видеть железку включенную в ONU2. Теоретически. А практически - МПХ, если с железки в ONU1 попытаться попинговать железку воткнутую в ONU2, то ARP запросы уходят, на стороне второй железки их видно, железка отвечает, но

Все свичи во время грозы любят выгорать портами. При этом с вероятностью в 90% на этом порту образуется кольцо. Умные свичи можно настроить так, что-бы они ловили кольца у себя на портах. Тупые свичи так настроить нельзя. Несколько раз я видел так выгоревшую сетевуху. Что такое кольцо на порту - знающие и так знают, а не знающим (и не настраивающим ловлю колец) я могу только поклониться - смелые люди. Еще бывают случаный и злонамеренные случаи.

Проигнорирует. Точнее - попучит ошибку но особого внимания на это не обратит.

OLT1_config_epon0/2:5#epon onu port 1 loopback detect OLT1_config_epon0/2:5#sh run int epo 0/2:5 Building configuration... Current configuration: ! interface EPON0/2:5 onu-configuration description 1G epon onu port 1 loopback detect !!onu-configuration-end OLT1#sh ver BDCOM(tm) P3310B Software, Version 10.1.0B Build 9545 1501C ?

Я что-то лоханулся и не проверил. А тут. Внезапно. ОНУ = 1501C epon onu port 1 loopback detect Jul 8 10:11:34 HAL: set onu port loopback detect failed: rc = 135 epon onu port 1 storm-control mode 2 threshold 1024 Jul 8 10:11:54 HAL: set onu port storm control failed: rc = 134 no epon onu spanning-tree Jul 8 10:12:52 HAL: set onu stp mode failed: rc = 135

http://lasermotive.com/products/power-over-fiber/ Надо попросить BDCOM встроить в OLT и ONU.

1.3.6.1.4.1.3320.101.10.5.1.5

возврат ремонтных ОНУ. Т.е. возврат и очередная гроза запустит круг снова? Сурово. 1. Все рекомендации Павлабор (огромное ему спасибо) были направлены производителю с картинками. думаю все расписано очень толково, будем надеяться что Владимир прав и причина именно в этом! 2. Любой ремонт подразумевает что это не повторится. Но если действительно проблема описана верно, то будем штось запаивать. 3. 150 сменных модулей выезжают к нам. Ну модули и мы сами можем перепаевать, если ты нам штук 15 пришлёшь. У меня ребята вплоть до реболлинга умеют. Другой вопрос - что будет с гара

возврат ремонтных ОНУ. Т.е. возврат и очередная гроза запустит круг снова? Сурово.