клиента это не волнует совсем

на конце ставятся два пробника

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

клиент видит картину и понимает, что жопа

выкатывает претензию

начинаем разбираться

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

пакеты берет и не отдает

все пиздим Петю

Дим, то же самое, только наоборот разбираться начинаем ДО того, как позвонит клиент

еще раз

разбираться начинаем, имея объективную картину

у меня была идея с 2 порогами

для клиента и для себя

сами дергаемся, когда срабатывает наш порог

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

а теперь в другую сторону

мы -- клиент

з/о по порту оператора

кроссировку мы заказывали отдельно

мы видим, что из конца в конец у нас жопа

нет

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

мы - оператор

дим

NOC может использоваться и там и там

мы - оператор

Мы оператор и мы заказываем каналы как клиент

да смотри. у нас канал, идущий через 10 железок

на железке, стоящей в середине видим такое: WARN: Broadcast storm is occurring (port: 13)

это означает, что канал, идущий через эту железку уже не 100% качества

ты опять полез в детали

я рассказываю, как оно реально звонит клиент, жалуется на качество наши действия - заходить на все 10, 20, 30 железок, через которые идет канал, и смотреть, на какой из них проблема

я рассказываю, как оно реально звонит клиент, жалуется на качество наши действия - заходить на все 10, 20, 30 железок, через которые идет канал, и смотреть, на какой из них проблема

а если железо не в вашей зоне ответственности и доступа нет?

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

смотреть все железки в нашей зоне ответсвенности

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

после звонка начинаем, на каждой железке show log show error ports N show ddm ports N cable diag ports N

https://www.evernote.com/l/ADndseLG3zNJaY_qqEDq488-sch2QUuG5lc

Дим, давай автодиагностику попробуем потом обсудить

вот третий вариант

Канал продолжает быть арендованной сущностью

к нему есть подключение

каждое подключение -- список услуг и зон ответсвенности

они типизированы

порт -- это порт, выделенный под канал

еще есть кроссировка

и до кучи -- чужие vlan'ы

а то и другие vpn'ы

Порт "промежуточной" железки тут предусмотрен ?

теоретически можно

достал попкорн

у нас операторы дебилы Пропадает электричество на промежуточном узле а они еще пол-часа звонят, и спрашивают, почему не работают каналы, проходящие через этот узел

у нас операторы дебилы Пропадает электричество на промежуточном узле а они еще пол-часа звонят, и спрашивают, почему не работают каналы, проходящие через этот узел

РТ тоже порой не знает о проблеме, а все лежит к хуям

перефразировал

Вот. Поэтому мы должны "плясать" от MO. Если проблема с MO - то деградируют каналы, через него проходящие

Вот. Поэтому мы должны "плясать" от MO. Если проблема с MO - то деградируют каналы, через него проходящие

проблемный МО может быть не в нашей зоне ответственности и управлении

Может. А может быть и в нашей.

его вообще нет в ноке, допустим

да пофиг у нас типичная ситуация проблемы UA-IX через него идет несколько каналов разных клиентов

эта штука нужна, чтобы РТ знал о проблеме

Правильно. Только проблему нужно локализовать до того, как позвонит клиент

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

вот я и хочу

смотри

логика такая

если у нас указан порт

и он или железка лежит -- канал подшиваем в аварии

там хоть в fm.alarms выводи -- какие каналы валяются

и он или железка лежит -- канал подшиваем в аварии

+

да, но не только "конечная" железка, а и промежуточная

любая

для которой задан порт

если ты их там десять указал -- твое право

любая неработающая -- цепочка оборвалась

т.е. "канал" у нас состоит из "железок" и "портов" на них

нет

это дурной вырожденный случай

если у нас промежуточная циска написала "%FABRIC-3-CRC: Switch card 1", то это явно не улучшит качество канала, проходящего через нее

@dvolodin видимо хочет фактами оперировать, а ты на предотвращение @dmitryluhtionov

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

У нас для этого есть FM и метрики

https://www.evernote.com/l/ADndseLG3zNJaY_qqEDq488-sch2QUuG5lc

вот четверный вариант

через сервисную модель

то же, что и в 3-м

но не вводя лишних сущностей

Дим. Проблема может быть не только на порту, но и на самой железке. Те же CRC ошибки на TCAM

как это вляет на модель данных?

кроме порта нужно еще и MO туда засунуть

как это вляет на модель данных?

порт не упал - не подшили к каналу аварию на железке

@dmitryluhtionov по хорошему поиск железок по которым проходит канал надо автоматизировать

иначе убиться можно забивать 1000 каналов руками

ага

учитывая что через железку их может много проходить

на самом деле даже автоматизировать не надо

для железки понятны все сервисы, которые от нее зависят

например C6KENV-SP-4-MINORTEMPALARM: RP 1/0 inlet temperature crossed threshold #1(=50C). It has exceeded normal operating temperature range. вполне может влиять на деградацию канала

канал -- тот же сервис

тут дело вот в чем