"Засветка" OLT-а лямбдой 1310 - а был ли мальчик?

[axl72 12]

в

 

 

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

 

Был ограничен временем и ресурсами.

А уровень в  случае включения медиков и сфп действительно суммируется, и это подтверждается измерителем включенным в корень дерева, я же цифры привел.

 

С остальными замечаниями согласен. действительно, горящий светодиод PON не является гарантией успешной передачи данных. Но каким образом можно мониторить BER ? есть ли средства для этого на онушке и на олте? и можно ли эти данные снимать по SNMP? 

[ZuarasiZ 37]

Вчера случился "мальчик", и очень кстати.

 

Мощность сигнала с OLT на абоненте около -20,0 дБ (1х2 + 1х32). Всего было два абонента на дереве. Только начали подключение по этой ветке.

 

Используется гибридная сеть F-Ethernet + GEPON. Почему так, отдельная история.

 

Монтажник "по запаре" включил медик 1310 туда, где должна быть ОНУшка.

В результате - медик 1310 поднял готовность. Настраивать монтажник не стал, отложил на завтра по причине, что уже было поздно.

 

И вот началось. Звонок от одного из клиентов, нет Инета.

 

Проверяю.

Одна из двух ОНУшек стала в режиме deregistered, link down.

Вторая авторизована, и по ней как ни в чем не бывало бегает трафик.

У "проблемного" клиента ставим другую ОНУшку. Новая ОНУшка зарегистрировалась, по ней пошел трафик. На этом откланялись, ушли.

 

Снова звонок - "тупит" интернет, и хрошо что пользователь программист, сказал что теряются пакеты - более 30% потерь.

 

Пингую обе ОНУшки, на одну - 0% потерь, на вторую 30...50% потерь. Чешу репу, откладываем вопрос до вечера.

 

До вечера попадаю сам к новому клиенту, и вижу наш медик. Поставил ОНУшку, и все проблемы прекратились.

 

Вот как то так для нас все удачно сложилось, я получил нужный опыт не на ветке с 50+ пользователей.

[pavlabor 1 914]

Гайджин, считает что пингование это признак ламеризма,

и 30...50% потерь, это абсолютно ничего не означает,

а ситуация не интересная потому что - бессистемная.

Відредаговано 2013-09-27 08:41:56 pavlabor

[KaYot 3 679]

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

[ZuarasiZ 37]

Фостер, потрите померите этих кавбоев клавиатуры. Честно, надоел этот СРАЧ!

[_WesT_ 1 016]

Вчера случился "мальчик", и очень кстати.

 

 

Это не совсем тот "мальчик". Этот пример только доказывает что строить гибридные сети - чревато. 

А можно уточнить какой именно медик использовался? Просто интересно что за медик с легкостью преживал 23Дб затухайний.

[pavlabor 1 914]

Фостер, потрите померите этих кавбоев клавиатуры. Честно, надоел этот СРАЧ!

Кто такой Фостер, и что значит срач?

Я считаю что пропинговка, может показывать проблему,

в данном случае мне интересно работала и падала онушка в одном дереве, или разные деревья,

есть какая то зависимость на делителях?

Если такая зависимость есть, то можно пытаться построить алгоритм более точного определения паразитного источника.

 

И опять же как по мне то развернуть смокепинг, под силу многим,

в отличии от опроса головы.

Более того, результаты смокепинга, более понятны для сапорта, чем децибелы.

 

И в отличии от Гайджина, я не вижу тут абсолютно никаких аномалий, кто как хочет так и организовывает мониторинг.

 

Тереть эту мысль, конечно хорошая идея, только сначала предложите, альтернативную систему мониторинга.

Потому как у нас, смокепинг, пока единственная система, комплексного, глобального мониторинга пона,

альтернативы не вижу.

Відредаговано 2013-09-27 11:06:10 pavlabor

[ZuarasiZ 37]

pavlobor, Вы не внимательны. Я все достаточно точно описал, что произошло.

 

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

 

_WesT_, - медик обычный 100M WDM 1310, 20км, TKO.

[pavlabor 1 914]

pavlobor, Вы не внимательны. Я все достаточно точно описал, что произошло.

 

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

 

_WesT_, - медик обычный 100M WDM 1310, 20км, TKO.

Я читал внимательно,

из "у одного" и "снова тупит", делаю выводы что что глючил линк только у одного абонента.

Все три источника были включены в делитель 1х32, а тот в делитель 1х2.

Есть идеи почему на одной онушке не было выпадений а на другой были?

Длинна, модель...?

 

И насколько, выпадений, не было?

Мы устойчивость линка проверяем так

ping -f -s 24000 10.180.237.1

отличным линк считается при выпадениях 0.1-0.5% на 5-10 тыс. пакетов.

[lex_auto 2]

может не совсем по теме, ситуация такова.

Знакомый строит GePON маскалям и был у них такой случай неделю назад!

легло все дерево !!  

не кто не чего понять не мог !! пока разобрались! оказалось!!

 

Обозленный абон ! за то что его отключили,  нашел где то карман под SFP и засунул в него 40км сфп модуль и включил в ветку !!

 

все легло !!! и лежало пока не разламали его волокно !!!

после разговора с ним он демонстративно показал чем положил !!!

[laffytaffy 84]

Мда... Кто там про Киев писал, что там за 100 грн. кроме интернета еще операторы абоненту должны?   Походу абоненты включенные PONом получат либо по морде либо то, что они хотят

[axl72 12]

а что означает команда 

 

show epon always-laser-on-onu ?

 

 

PS: О.. это мой сотый пост! теперь могу жмакать красные и зеленые кнопочки! 

Відредаговано 2013-09-27 16:02:26 axl72

[lex_auto 2]

что  мешает не чистым на руку конкурентам сделать нечто подобное ??

подключат свое человека и давай терзать все дерево абонов..

[ZuarasiZ 37]

 

pavlobor, Вы не внимательны. Я все достаточно точно описал, что произошло.

 

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

 

_WesT_, - медик обычный 100M WDM 1310, 20км, TKO.

Я читал внимательно,

из "у одного" и "снова тупит", делаю выводы что что глючил линк только у одного абонента.

Все три источника были включены в делитель 1х32, а тот в делитель 1х2.

Есть идеи почему на одной онушке не было выпадений а на другой были?

Длинна, модель...?

 

И насколько, выпадений, не было?

Мы устойчивость линка проверяем так

ping -f -s 24000 10.180.237.1

отличным линк считается при выпадениях 0.1-0.5% на 5-10 тыс. пакетов.

 

Пардон! Я думал что моя запись 1х2 + 1х32, будет пониматься, как:

корневой делитель 1х2, к нему подключены два делителя 1х32, и уже к ним включаются абоненты.

 

Все три абонента были на одном делители 1х32.

 

Первых две ОНУшки 1004B были из одной поставки. Потом поменяли №2 на ONU из свежей партии, предварительно удалив ее запись с ОЛТа. Клиенту №3 поставили освободившуюся ONU от второго клиента.

 

Сейчас стало так:

Switch#show epon onu-information interface epon0/2
Interface EPON0/2 has registered 3 ONUs:
IntfName   VendorID  ModelID  MAC Address    Description     BindType  Status          Dereg Reason
---------- --------- -------- -------------- --------------- --------- --------------- -----------------
EPON0/2:1  BDCM      3022     fcfa.f7c5.0c07 N/A             static    auto_configured N/A
EPON0/2:2  BDCM      3024     fcfa.f796.364b N/A             static    auto_configured N/A
EPON0/2:3  BDCM      3022     fcfa.f7c5.0c0d N/A             static    auto_configured N/A

Switch#show epon optical-transceiver-diagnosis interface epon0/2:1
 interface    RxPower(dBm)
-----------  --------------
epon0/2:1    -21.8
Switch#show epon optical-transceiver-diagnosis interface epon0/2:2
 interface    RxPower(dBm)
-----------  --------------
epon0/2:2    -21.2
Switch#show epon optical-transceiver-diagnosis interface epon0/2:3
 interface    RxPower(dBm)
-----------  --------------
epon0/2:3    -23.0

Switch#show epon optical-transceiver-diagnosis interface epon0/2
 interface    Temperature(degree)    Voltage(V)    Current(mA)    TxPower(dBm)
-----------  ---------------------  ------------  -------------  --------------
epon0/2      42.8                   3.4           10.5           4.1

Второй день, полет нормальный.

[axl72 12]

что  мешает не чистым на руку конкурентам сделать нечто подобное ??

подключат свое человека и давай терзать все дерево абонов..

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

[lex_auto 2]

кусачки слишком явно!! 

а так можно терзать жестко и конкретно !!

Відредаговано 2013-09-27 16:42:05 lex_auto

[Гайджин 574]

Ндя... ZuarasiZ у Вас измеритель есть?

[ZuarasiZ 37]

Их у нас есть, иначе как бы я мерил сигнал у абонента? И причем тут ндя? "Мальчик" был, и был научен за самодеятельность

 

 

Во всей этой ситуации меня удивило, что все дерево не рухнуло, а частично стало вести себя не правильно.

 

1) Не все ОНУ отпали.

2) Те что остались, при почти одинаковых уровнях сигнала, вели себя по разному - одна ОНУ держала линию как ни в чем не бывала, вторая - стала терять пакеты, но при этом оставалась зарегистрированной на ОЛТе с хорошим уровнем сигнала.

3) Медиаконвертер WDM 1310 своей индикацией показал (готовность трех светодиодов в ряд), что удачно соединен по оптике.

 

Были так же промежуточные манипуляции включения-отключения ОНУ, удаления записи об ОНУ с ОЛТа, и т.д.

 

 

ЗЫ. Почему так получилось. Все просто. У меня оптический узел, в котором разварено 4 кабеля по 64 волокна. Дабы дальше не плодить F-Ethernet, а в дальнейшем вообще уйти от 220В, ИБП, охлаждения, вентиляции и смены фильтров, решили поставить ODF-панель с делителем 1х64. Вместо 1х64 поставили 2 делителя 1х32. Сварщик к концу дня (вечера) уже был на готов стоять на самых интимных местах, причем не только своих. И попутал МК с ОНУ. Более того, МК с ним сыграл шутку, и "мальчик" пришел в гости.

Відредаговано 2013-09-27 21:04:47 ZuarasiZ

[Гайджин 574]

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

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

Вывод: ндя... печалька... этот "бой" Вы проиграли...

Відредаговано 2013-09-28 06:42:12 Гайджин

[pavlabor 1 914]

Я не совсем то хотел сказать.

 

Думаю что нужно определить структуру стенда, и параметры которые нужно получить,

потому как, лично я не совсем понимаю что собственно требуется выяснить.

 

Дерево должно падать однозначно, и то что там работала одна онушка без выпадений, это странно.

Возможно тут имеется кратность 100 и 1000 мегабит, но голова то формирует несущую не 1000 мегабит,

и в любом случае несущие должны перетрескаться и медик должен "сбивать" синхронизацию головы,

в этом случае, должно разваливаться все дерево и опять собираться, опять же за это время что то но должно выпасть.

[axl72 12]

Почему? Я допускаю, что даже при условии идеального деления и абсолютно одинаковых затуханий на абонентских отводах разные онушки могут вести себя по разному. Разброс характеристик их SFF модулей никто не отменял. Когда одна начнет слегка терять пакеты, другая уже может быть в лоссах..

Відредаговано 2013-09-28 07:13:11 axl72

[pavlabor 1 914]

Почему? Я допускаю, что даже при условии идеального деления и абсолютно одинаковых затуханий на абонентских отводах разные онушки могут вести себя по разному. Разброс характеристик их SFF модулей никто не отменял. Когда одна начнет слегка терять пакеты, другая уже может быть в лоссах..

Не думаю что китайцы придумали что то новое, все это уже придумано до нас,

базовая передача примерно такая

http://ru.wikipedia.org/wiki/Плезиохронная_цифровая_иерархия

 

и если смотреть на то как работает Е1, то там видно что даты 30 каналов, а физически передается 32 канала,

существует такое понятие как синхрометка и передача синхронизируется на каждом цикле.

 

В гепоне, в отличии от Е1, не фиксированное окно на канал/устройство, а плавающее,

это позволяет при нагрузке на одной онушке, увеличивать количество фреймов на нагруженную онушку.

 

Если смотреть как МОЖЕТ работать онушка,

 то там примерно такие идут процессы.

 

Голова формирует несущую,

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

Голова, смотрит на текущую ситуацию, подвигает существующие устройства и отводит полосу для новой онушки.

 

В результате работы гепона,

идет несущая, она разбита на сегменты, и каждый сегмент закреплен за конкретной онушкой.

Когда приходит очередь онушки, она передает данные, остальное время молчит, потому как данные передают другие онушки,

еще онушка постоянно слушает синхометку и корректирует свою частоту.

 

Теперь берем соточный медик и втыкаем,

во первых у него частота в десять раз меньше, а такты в 10 раз больше,

и при одном чихе медика, валится 10 тактов на приемнике головы.

 

Если бы на медике линк не поднялся, то это означает что медик, периодически будет отправлять запрос на поднятие линии,

но если все три лампочки загорелось, это означает что линк поднят, и медик начал транслировать несущую.

 

Несущая, это постоянные импульсы, генерируемые генератором медика на передатчике,

на несущую накладывается данные,

на приемнике, с потока вычитается несущая и получается чистая дата,

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

 

Так вот медик, своей несущей, должен разрушать синхрометку,

в результате должна сбиватся синхронизация головы и онушек,

и дерево должно рассыпаться.

 

Если импульс от медика будет попадать на дату,

то дерево может остаться целым, но должно появляться выпадение на онушках.

Так как работа головы и онушки не кратная, то должно появится плавающее окно,

которое будет в процессе передачи дрейфовать относительно синхрометки,

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

Технически это очень быстро, за секунду, сто миллионов только на медике и миллиард на голове,

практически визуально невозможно даже один пакет зарегистрировать.

 

Возможно китайцы что то придумали, для подавления этой проблемы,

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

Проблема в том, что свет он как бы определенного спектра, тут играть неначем,

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

Более того, засветка соточным медиком, сразу 10% окна вываливает в утиль,

не вижу за что можно зацепится.

 

Та контора которая выпустит чип с решением этой проблемы, у кого будет круче алгоритм регенерации сигнала, тот и победит.

Відредаговано 2013-09-28 08:55:59 pavlabor

[ZuarasiZ 37]

Дерево все целиком не упало. Мои выводы безсистемные - потому что это не стенд, а живые абоненты, к которым я отношусь не как к подопытным кроликам. Свою проблему с "мальчиком" я решил. Более того, я стал знать, как дерево может себя повести в полевых условиях. В лабораторных - при делителях 1х8 + 1х8 - да, все дерево (из двух ОНУшек) рухнуло. Это оказалось не показателем. Потому что в поле из 3х ОНУ имеем следующее:

1) одна ОНУ - выпала. По индикации на ней состояние не ЛОСС, а постоянная синхронизация (мигающий ЛИНК)

2) вторая ОНУ - работала так, как ни в чем не бывало.

3) третья ОНУ - работала, но теряла пакеты.

 

На ОЛТе вторая и третья ОНУ показывались как полностью рабочии, без каких-либо аномалий. По крайней мере я не смог их найти. Лично мне помог случай.

 

И забыл сказать, в медик медный патчкорд не был вставлен.

Відредаговано 2013-09-28 08:35:33 ZuarasiZ

[pavlabor 1 914]

Есть как бы такая идея.

Голова тактуется не на 1.25гига, а на 1.0гиг,

При этом синхрометки могут иметь одинаковую структуру, и кратный диапазон синхронизации,

засинхронизировав одни раз, голова засунула медик в какой то диапазон и не парится,

медик 9 синхрометок тупо не видит, по десятой синхронизируется с головой,

получается частота зафиксировалась и на голове и на медике.

 

Дальше, так как медик данные не передает,

то возможно что кроме синхометок там нечего и не ходит

возможно что медик, периодически плюется каким то пакетом "хеллоу"

в результате медик попадает своим "хеллоу", именно в диапазон работы второй онушки, дата сыпится на уровне приемного канала головы.

 

В таком случае дерево остается целостным, более того, может частично работать при хорошей нагрузке и без выпадений.

 

Чтобы надежно положить дерево, нужно воткнутся медиком в дерево и флудонуть.

Відредаговано 2013-09-28 09:23:53 pavlabor

[Гайджин 574]

Господа хорошие, Вы бы не метались из крайности в крайность - то пинги, то несущие, то все дерево упало, то не все...

 

1. При возникновении ситуации называемой как "засветка", первым делом нужно было оторвать дерево от ОЛТа и измерителем на 1310 померять уровень 1310, прилетающий из дерева. После устранения "засветки" нужно было измерить уровень передатчика 1310 на медике. При установке ОНУ клиенту необходимо проходным измерителем измерять и сохранять для дальнейшего анализа уровни по 1310 и 1550. - Этого сделано не было.

2. При описании ситуации называемой как "засветка", проследить хронологическую последовательность действий персонала (ставили и переставляли ОНУшки и т.д.) не удается. Приведенные в данной ветке скриншоты уровеней сигналов тоже не удается как либо связать с самим повествованием.

3. Разговоры о тактовках, синхрометках,их разрушении и т.д. минимум преждевременны ибо у ZuarasiZ в дереве с коэффициентом деления 1х64 всего три ОНУшки, разница в затухании между которыми 2.8 дБ (почти в два раза!), а затухание ОЛТа до самой "дохлой" ОНУ 26 дБ.

 

Я прекрасно понимаю, что восстановить картину и получить недостающие для анализа данные уже не получится - вывод: этот бой слили...

Відредаговано 2013-09-29 10:11:07 Гайджин