ufm

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

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

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

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

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

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

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

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

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

Сейчас стенд разобран, если будет время завтра - соберу обратно. Впрочем, там по любому ничего экзотичного быть не должно. MAC первого компьютера должен быть виден на порту ONU в влане два, на гигабитном порту OLT в влане 3. На свиче - на первом порту в влане 2 и на третьем порту в влане 3. MAC второго компа - в зеркальном виде. При указанных настройках и ONU и OLT запрещен внутренний свитчинг, только через внешний роутер. Соответственно прохождение пакета со второго порта на первый: 1. Попадаем на ONU через второй порт в третьем влане. 2. Входим с ONU на OLT в влане 3. Видим dest mac в нашем влане на гигабитном порту и отправляем пакет туда 3. Входим на свич. Видим dest mac в нашем влане на 3 порту и отправляем пакет туда. 4. Выходим со свича без тега, заходим обратно с тегом 2 5. Видим dest mac во втором влане на 1 порту, уходим туда. 6. Выходим с первого порта и попадаем обратно на OLT. Видим dest-mac в нашем (втором) vlan на ONU. отправлем пакет туда 7. Заходим на ONU видем dest-mac в первом порту и отправляем пакет туда. 8. Выходим с ONU без тега через первый порт. Да ну? Это все "ваша" логика реальные выводы в студию.Для спеца вашего уровня - реальный вывод это основа это я тут так балуюсь. Это не то что бы "моя" логика. Это стандарты. Но вот честно - грешен. Я как-то не подумал что bdcom действительно пофигистичен к стандартам. Завтра проверю.

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

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

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

Проблема с прохождением 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 mode 2 threshold 1024 epon onu port 2 loopback detect epon onu port 2 storm-control mode 2 threshold 1024 epon onu port 3 ctc shutdown epon onu port 3 loopback detect epon onu port 3 storm-control mode 2 threshold 1024 epon onu port 4 ctc shutdown epon onu port 4 loopback detect epon onu port 4 storm-control mode 2 threshold 1024 OLT настраиваем так: interface GigaEthernet0/1 switchport trunk vlan-allowed 1-4000 switchport mode trunk interface EPON0/1 epon pre-config-template t2318 binded-onu-llid 1-64 epon bind-onu mac fcfa.f796.44db 1 switchport trunk vlan-allowed 1-4000 switchport mode trunk switchport pvid 1000 switchport protected Втыкаем OLT в первый порт свича. Порты на свиче настраиваем так: 1 Port - Tagged vlan2, tagged vlan 3 2 Port - Access vlan 2 3 Port - Access vlan 3 Соединяем патчкордом порты 2 и 3 (это vlan translator. Его можно сделать любым удобным способом, главное - прозрачный перенос трафика между vlan2 и vlan3. Этот - самый простой). Подключаем первый компьютер к первому порту ONU, второй - ко второму. Что мы получили: Весь трафик с компьютера 1 через порт 1 ONU должен уходить в vlan2 на свич, на свиче перетегироваться в vlan3 и возвращаться на порт 2 ONU. Компьютеры должны видеть друг-друга как будто они соеденены напрямую. Что происходит в реальности: Между компьютерами ходят только бродкастовые пакеты. Это легко проверяется. 1. ping с одного компа на другой. На компьютере с которого делаем пинг видим только исходящие ARP REQUEST бродкасты. На втором компьютере видим бродкасты и ответы. На vlan translator видим бродкасты и ответы. 2. ping -b с бродкастовым адресом - видим пакеты на обоих компьютерах. 3. Добавляем статикой mac адрес второго компьютера на первый и видим icmp на первом компьютере и на vlan translator. На второй компьютер icmp не приходит. Какой компьютер первый а какой второй - не важно. Ровно тот-же эффект, если использовать вместо одной - две ОНУ на одной ветке. Я подозреваю, что и на разных ветках будет тоже самое, но проверить не могу. На разных OLT (две ону, одна включена в одну OLT, вторая - в другую, OLT включены в свич с транслятором) - всё работает.

А вот фиг. Всё равно 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 запросы уходят, на стороне второй железки их видно, железка отвечает, но до первой железки они не доходят. И так продолжается, пока ONU1 и ONU2 не назначены IP адреса. Т.е. после чего-то типа epon onu ip address static 10.222.8.2 255.255.252.0 gateway 10.222.8.1 vlan 1000 всё действительно начинает работать. прошивка в ОНУ - 1107 Сама ОНУ - 1004B

Все свичи во время грозы любят выгорать портами. При этом с вероятностью в 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 пришлёшь. У меня ребята вплоть до реболлинга умеют. Другой вопрос - что будет с гарантией, если модуль мы сами заменим и выяснится что не помогло.

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