Регламент оператора для работы с системой мониторинга IP сети.
1. Назначение данного документа.
Документ описывает, как правильно использовать IP мониторинг в операторской
службе RELCOM, а также регламентирует ведение журнала и комментариев к
событиям. Подробное описание того, как работает монитор и как вызываются
его подменю и окна, имеется в документе "Руководство пользователя
по системе IP мониторинга".
2. Вызов монитора.
Монитор вызывается на рабочей станции операторов (или на нескольких
станциях), по одному монитору на каждую сеть, подлежащую контролю.
В первой версии системы ведется мониторинг одной сети - сети RELCOM,
то есть вызывается один монитор, пока - на машире bounty (SUN 2 у операторов);
еще один монитор будет постоянно висеть на рабочем месте оператора в помещении
NOC.
Порядок входа в систему и вызова Netscape определяется отдельной инструкцией,
так как зависит от рабочей станции и ее настройки.
Далее нужно войти в начальное меню мониторинга, установить правильный
режим звука и вызова (лучше использовать режим отдельного окна), и вызвать
основное окно монитора. Для операторорской службы рекомендуется использовать
кнопку [MenuAndTotal], но возможно и [AllInOne] (полный экран); можно также
вызвать малое окно, и из него вызвать основной экран.
Желательно, чтобы на экране всегда находилась выдача одного из экранов:
[полный] или [алармы]. Абсолютно необходимо иметь на экране выдачу суммарной
информации (она входит во все формы представления монитора на экране, но
в определенных условиях может быть потеряна).
При приходе новой смены монитор желательно перевызвать, чтобы авторизоваться
в системе под правильным именем, а также чтобы не исчерпывать оперативную
память рабочей станции (которая исчерпывается при очень длительной работе
одного и того же Netscape-а из за ошибок в нем). Для этого нужно или полностью
перевызвать экран X/Windows, или выйти из Netscape (кнопкой Destroy, или
выполнив DELETE на всех его окнах) /работа с X/Windows описывается отдельно/.
Важно, чтобы при авторизации в системе были введены имя и пароль текущей
смены операторов, а не оставлены предыдущие.
В следующих версиях эта проблема будет упрощена - система сама будет
требовать ввести заново имя и пароль при переходе через границу смен.
По завершении вызова на экране операторов должны быть доступны:
- Основное меню (в котором делается выбор [полный], [алармы] и так далее);
- Меню суммарной информации (SUMM);
- Центральный экран с результатами полного мониторинга либо мониторинга
алармов.
Окна ROUTER и LINK можно заранее вызвать и разместить на соседней панели
виртуального экрана, если это поддерживается системой X/Windows, подробно
эти тонкости будут описаны в руководстве по рабочей станции операторов.
3. Регламент работы.
Задачи круглосуточной службы мониторинга, связанные с IP монитором,
следующие:
- В случае тяжелых аварий системы - определять такие аварии и предупреждать
специалистов, ответственных за работу системы в целом. В то же время важно
не перепутать аварию, показанную из за ошибочной настройки системы мониторинга,
с действительно тяжелой аварией системы;
- Предпринимать меры по восстановлению работоспособности роутеров при
их отказе (остается в силе такое же примечание, как и к предыдущему пункту
- в первую очередь нужно быть уверенным, что имеется отказ роутера, а не
сбой системы мониторинга);
- Предпринимать меры по восстановлению работоспособности внутренних и
клиентских каналов, в той степени, в которой это возможно (особенно это
касается клиентских каналов).
- По каждому аварийному событию - делать запись в журнале о его причинах
и предпринятых действиях, и устанавливать статус события соответствующим
полученной при выяснении причин информации.
- При обнаружении неточной информации о каналах или других объектах -
делать запись об этом в журнал и передавать информацию для группы, ведущей
такую информацию (LINKS или NOC).
Естественно, что самое сложное - отделять действительно важные события
от событий, которые связаны только с конкретным клиентом, а их, в свою
очередь, от событий, которые не требуют никаких действий по той или иной
причине. Поэтому данная версия регламента устанавливает не жесткие правила,
а принципы работы, постепенно по мере освоения системы регламент будет
дополняться регламентами обслуживания конкретных подсистем (и эти регламенты
делаться доступными через тот же монитор), а также будет корректироваться
информация об объектах мониторинга, имеющаяся в системе.
3.1. Классификация объектов мониторинга.
Мнемоническая схема сети, позволяющая наглядно оценивать важность
и взаимосвязи ее элементов, находится в стадии подготовки. Вероятно, будет
использоваться какой либо монитор с графическими возможностями отображения,
чтобы обеспечить наглядность и упростить анализ сбоев этой сети.
Определить категорию объекта достоверно можно только, наработав некоторый
опыт, и введя соответствующую информацию в базу данных. В следующей версии
системы предполагается дополнить карточки объектов информацией о регламенте
их обслуживания и их важности. Тем не менее, для сети RELCOM можно условно
разделить объекты на категории следующим образом:
3.1.1. Особо важные, определяющие работу всей сети в целом, и находящиеся
в нашей компетенции.
Как правило, такие элементы сети дублированы так, что отказ одного из
них не должен вызывать развала всей сети (но, как показывает практика,
может из за разного рода ошибок), но отказ двух и более особо важных элементов
часто может вывести сеть из строя полностью. При отказе такого объекта
необходимо принять меры к восстановлению его работы (или получить информацию
о предполагаемых причинах и времени исправления отказа) как можно быстрее.
Таблица 1. Роутеры базовой сети RELCOM и каналы, соединяющие основные
ее элементы. На 10 декабря 1997 года это следующие элементы сети:
площадка ЗАРЯ |
|
площадка ИАЭ |
|
|
Площадка M9 |
|
|
Площадка SPB-1 |
|
|
|
|
RTK-2-Внешний мир |
|
Российские сети |
|
|
 |
|
|
|
Et1/2 |
M9-11 |
M9-11-IX |
|
|
DAWN-1 |
|
KIAE-3 |
|
|
|
|
|
|
kiae-m9-eth |
M9-11-KIAE |
|
|
|
|
node |
|
|
локальная |
|
|
|
|
локальная сеть |
|
|
сеть |
|
|
|
DAWN-2 |
KIAE-4 |
KIAE-M9-2M |
M9-2-KIAE |
M9-2 |
M9-SPB-2M |
SPb-M9 |
SPB-1 |
|
|
|
|
|
|
|
|
MSK-AMS(1)
MSK-AMS(2) |
|
|
|
|
|
|
|
Внешний мир |
|
!!! |
|
spb-Hki-2M |
|
|
|
|
|
|
Амстердам |
|
Хельсинки |
Здесь жирным шрифтом показаны критические роутеры, а жирным наклонным
шрифтом - критические каналы (это должно бы быть картинкой, но пока существует
в таком табличном виде). Эти объекты соответствуют пункту (1). Особо критичным
является отказ сразу нескольких элементов одного типа, например отказ двух
роутеров на M9, или отказ и канала на Амстердам, и канала на Хельсинки,
или отказ обоих роутеров в KIAE.
3.1.2. Важные объекты, которые однако влияют только на работу клиентов,
с ними связанных.
В основном это - роутеры, обслуживающие клиентов. Так, отказ роутера
M9-5 приводит к отказу у всех клиентов, работающих через него, но не приводит
к последствиям для остальной части сети. Принципы работы с ними примерно
такие же, как и в пункте 1, но с меньшим приоритетом.
Это - роутеры KIAE-??, M9-??, DAWN-??, SPACE-??, SPB-??, кроме перечисленных
в табличке.
3.1.3. Особо важные объекты, находящиеся однако вне зоны нашей компетенции.
Их отказы необходимо отслеживать, поскольку они влияют на работу сети,
и иногда их последствия могут быть уменьшены с помошью ручных настроек.
К ним относятся
- роутеры сетей EUnet, RTK и Демос:Helsinki2,
- Pen1,
- Amsterdam2,
- Vie2,
- RTK-M9-2
- каналы между ними
- NY-Hki-1:2M,
- NY-Ams2:16M,
- NY-Ams5:16M,
- NY-Hki-2:2M,
- Hki-NY-1:2M,
- Hki-EUnet,
- Hki-Ams,
- Hki-NY-2:2M,
3.1.4. Клиентские каналы и роутеры, работающие в нормальных условиях.
К ним относятся все каналы, подключенные к роутерам RELCOM, кроме тех,
на которые сделаны комментарии, утверждающие обратное (наладка, выключается
и прочее).
3.1.5. Клиентские каналы, выключаемые случайным образом,
Имеется довольно много клиентов, выключающих свое оборудование на выходные
или на праздники, и тем самым делающими невозможным контролировать их каналы.
Такие каналы должны помечаться постоянными комментариями в системе мониторинга.
3.1.6. Объекты, не относящиеся напрямую к RELCOM, а относящиеся к другим
сетям (и в какой то степени влиящие на работу RELCOM).
К таким объектам относятся:
- DEMOS и его каналы;
- RTK и его каналы
- RBnet и его каналы;
- Свитчи северного бэк-бона nmbb-*;
- Сеть RELARN.
По ним невозможно предпринять активные действия (исключая случаи, когда
их мониторинг входит в сферу обязанностей операторской службы), но поскольку
их работа влияет на работу основной сети, полезно получить информацию о
аварии от центра управления соответствующей сетью или канального провайдера.
3.2 Общая процедура реакции на аварию:
- Определить, является ли авария действительно аварией объекта, или индикация
вызвана другими причинами.
- Определить, в какую категорию попадает аварийный объект. В будущем
регламент обслуживания будет прописан в карте объекта, а на сегодня приходится
пользоваться данными из регламента и из схемы связей сети.
- Если на объект есть карта объекта, то есть он учтен в базе каналов,
то там должны быть контактные телефоны и трасса объекта, позволяющие связаться
с провайдером канала (для цифровых каналов) или определить модем (для аналоговых
каналов) и попробовать предпринять активные действия для восстановления
работы. Если объект относится к компетенции RELCOM, активные действия должны
быть предприняты, если в журнале или карте не указано обратное, если не
относятся - как правило, активные действия невозможны.
- Если выясняется, что информация по данному объекту ошибочна, делается
запись в журнал объекта (не системный), где описываетс суть ошибки и по
возможности - правильные данные.
- В случае активных действий запись в журнале объекта делается и до,
и после их выполнения, чтобы исключить одновременные одинаковые действия
из нескольких мест (например, одновременные звонки на M9 из NOC, от операторов
и из Питера).
- Активные действия обязательны по следующим авариям:
- Авария роутера RELCOM, независимо от его важности в сети.
- Авария важного канала, который находится в нашей компетенции.
При этом, если самостоятельно восстановить работу и найти причину неисправности
не удалось, нужно сообшить об аварии специалистам NOC, отвечающим за данный
объект.
- Активные действия проводятся по остальным объектам, если это возможно
и если в журнале или комментариях нет указаний на противное.
- По остальным объектам достаточно определить по возможности причину
неисправности (связавшись с ответственными за объект) и создать комментарий
к данному событию.
3.2.1. Правила создания комментариев и установки статуса объекта.
При комментировании событий статус объекта устанавливается следующим
образом (это может пересматриваться по мере накопления опыта):
Код |
Название |
Назначение |
Аварийные состояния, выставляемые монитором |
E0 |
Только что упал |
Выставляется монитором при любой аварии, если ее продолжительность
меньше 2 минут. Служит для предупреждения о возможной аварии, и для того,
чтобы отличать кратковременные перебои (вызванные различными причинами)
от аварий, требующих вмешательства. Как правило, не требует реакции. |
E1 |
Авария |
Выставляется монитором при аварии продолжительнее 2 минут, и служит
сообщением _требуется вмешательство_. Если удалось определить причину аварии,
либо предпринять какие либо меры, и не требуется помошь остальных специалистов,
это состояние должно быть снято с помошью комментария. |
E4 |
Важная авария. |
Выставляется монитором вместо E1 либо по постоянному комментарию к
особо важным каналам, либо (в первой версии) автоматически для объектов,
имена которых написаны с большой буквы. Аналогично E1, но имеет больший
приоритет и как правило говорит о важности данного события. Требуется вмешательство,
если объект под нашей компетенцией, и запись в журнал, если не под нашей. |
Следующие состояния служат для комментирования
состояний, приведенных выше, и выставляются операторами: |
E2 |
Авария устраняется |
Выставляется в случае, если предприняты активные меры по устранению
аварии (сброс модема, сдача канала в проверку, или известна причина аварии
и прогноз на ее устранение). Сюда относятся все случаи аварий на магистралях,
если удалось получить от связистов сообщение _авария известна и над ней
работают_, а также случаи, когда оповещены соответствующие службы (сломался
модем и его заменяют). |
E3 |
Авария неустранима |
Выставляется в случае, если аварийный объект имеет важность для сети,
но предпринять меры по устранению аварии не удалось и требуется вмешательство
других служб RELCOM. Если объект аварии лежит вне нашей компетенции,
вместо этого кода нужно выставляnm U3 (ниже).
Выставлять это состояние всегда, когда аварийный объект нужно передать
в LINKS или NOC.
|
U3 |
Вне нашей компетенции |
Выставляется в случае, когда аварийный объект не контролируется нами
и активные меры не могут быть предприняты, если авария не носит затяжной
характер и объект представляет значение для сети. Примеры - аварии каналов
EUnet относятся к этой категории. |
U1 |
Не обращать внимание |
Выставляется в том случае, когда объект не представляет интереса с
точки зрения мониторинга - это никогда не работавший канал, или неверное
описан порт роутера (кроме случаев, когда это надо поправить какой то группе),
или клиент выключает оборудование. Не путать с состояниями E3 и U3. |
Следующее состояние выставляется монитором,
но может быть использовано и операторами, чтобы предупредить о неверном
описании объекта. |
U0 |
Нет данных |
Неверно описан порт, или нет ответа от роутера. Может быть использовано,
чтобы обратить внимание специалистов на некорректное описание о,бъекта |
Состояния предупреждения о перегрузке. Не требуют (обычно)
немедленной реакции, но служат предупреждением о возможных неприятностях. |
W0 |
Возникла перегрузка |
Только что возникла повышенная загрузка (процессора, канала). Не требует
реакции. |
W1 |
Перегрузка |
Длительная перегрузка. Перегрузка каналов обычно не требует реакции;
в то же время необходимо обращать внимание на такие объекты, потому что
например перегрузка процессора легко приводит к ложным срабатываниям системы
мониторинга (он не успевает отвечать на запросы), а может и говорить о
тяжелой аварии. Операторское вмешательство, как правило, не желательно. |
W2 |
Перегрузка неустранима |
Ставится системным администратором или оператором и говорит от том,
что данный объект хронически перегружен. |
4. Регламент обслуживания, используемый по умолчанию.
Ниже описаны действия при наиболее распространенных авариях, не учитывающие
специфику того или иного объекта. Более подробная информация будет постепенно
собираться в приложении к данному документу и в карточках объектов.
В следующей версии системы предполагается появления поля РЕГЛАМЕНТ в
карточке объекта, со ссылкой на описание регламента его обслуживания при
аварии. Для тех объектов, которые не имеют отдельных регламентов, нужно
использовать регламенты, описанные ниже.
При любой аварии прежде всего нужно убедиться в исправности монитора
- время в первой строке экрана (аларм, полный) должно соответствовать текущему
времени (возможна разница в несколько минут). Если время не соответствует,
нужно перевызвать монитор, а если это не помогает - сообщить в NOC или
программистам, сопровождающим его.
Еще один момент связан с запаздыванием мониторинга. Мониторинг показывает
картину сети с таким запаздыванием:
- Исходная информация собирается с интервалом в 30 - 40 секунд, то есть
процесс, работающий в фоне и собирающий данные, увидит аварию через 15
- 30 секунд;
- Экран с распечаткой по конкретному роутеру создается в момент его рисования,
то есть дает отставание в 15 - 30 секунд от момента рисования;
- Экраны [АЛАРМЫ], [ПОЛНЫЙ], [КОМПАКТНЫЙ] формируются раз в минуту, то
есть дают отставание от 15 секунд до полутора минут.
- Экран SUMM формируется раз в 30 секунд, то есть дает задержку 15 -
40 секунд;
- Выдача состояния интерфейса (при нажатии на название интерфейса) дается
на момент запроса.
Поэтому, если нет уверенности в том, исчезла ли авария или нет, нужно
вызвать окно полной распечатки по данному роутеру, и ориентироваться по
нему. В случае канала можно ориентироваться по выдаче состояния интерфейса.
4.1. Авария роутера.
- Убедиться, что роутер действительно не работает, не доступен или не
исправен. Признаки реальной неисправности таковы:
- Роутер не отвечает на попытку зайти на него. Зайти на роутер можно,
вызвав меню журнала и статистики по нему, по кнопке [войти]. Если при нажатии
кнопки вызывается отдельное окно, но в нем не выдается приглашение ввести
имя и пароль, то роутер не отвечает, если выдается - по крайней мере роутер
отвечает; /Внимание. Возможны роутеры, вход на которые таким способом
невозможен, поэтому наиболее показательным является невозможность войти
на роутер, на который обычно можно было войти];
- Авария подтверждается монитором модемов (showtty). [Возможна ситуация,
например отсутствие роутинга на PC M9-1 или M9-3, при которой монитор модемов
будет показывать нормальную работу, а монитор IP - показывать состояние
DOWN. Если такое продолжается больше 10 минут, и не восстанавливается само,
можно считать роутер неработоспособным].
- Авария подтверждается недоступностью каналов, подключенных к данному
роутеру. Для M9-2 например это каналы SPB1: SPM-M9 и KIAE-4: KIAE-M9.
- Попытки посмотреть состояние интерфейса на данном роутере (которое
выдается при нажатии на имя интерфейса) приводят к молчанию (не к диагностике
_запрос невозможен_) - это означает, что роутер не отвечает на запросы.
- Авария подтверждается жалобами клиентов.
Если роутер отвечает на часть тестов 1 - 4, то нужно руководствоваться
жалобами клиентов.
- Если роутер действительно не отвечает, нужно убедиться, что причиной
не стала авария других компонентов сети. Например, при аварии KIAE-3 или
северного бэк-бона (nmbb-*) станут недоступны роутеры DAWN-1, DAWN-2 и
PTT-1; при аварии канала на RTK - роутер RTK, при аварии канала на Питер
может быть частично или полностью недоступен роутер в Питере. Возможны
такие классы аварий:
- Авария канала, ведущего к роутеру. Это возможно, если канал не сдублирован;
в настоящее время сдублированы каналы между KIAE и M9, между M9 и Питером
(через RBnet), каналы на Запад. При авариях такого типа в состояние АВАРИЯ
будут выпадать сразу несколько роутеров (например, все роутеры Зари).
- Авария роутера, через который доступен другой роутер. Например, при
аварии SPB-1 будут недоступны прочие роутеры Питера.
- Авария локальной сети (свитча или хаба); при этом станут недоступны
те роутеры узла доступа, которые работают через локальную сеть (на M9 это
- все роутеры кроме M9-2 и в некоторой степени M9-11 и M9-9);
- Полная или частичная потеря роутинга из за исчерпания памяти или ошибки
конфигурации; при этом роутер может быть доступен одними способами и недоступен
- другими.
- Повышенная загрузка процессора роутера, из за которой он не успевает
отвечать системе мониторинга. Признаком такой аварии является периодический
возврат роутера в мониторинг, с правильным и большим временем жизни.
- Полный отказ роутера.
- В ситуациях 1 - 3 чинить нужно источник аварии, а не данный роутер;
в ситуации 5 иногда нужно провести перевызов роутера, но как правило достаточно
записи в журнале и сообщения специалистам; в ситуациях 4 и 6 желателен
перевызов, если другим меры не помогают.
- Если в регламенте не сказано противного, и нужны активные действия,
то действия при отказе роутера, после выполнения пунктов 1 и 2, следующие:
- Днем - проконсультироваться с дежурным NOC; а также попытаться связаться
с специалистом LINKS, если он есть на той площадке, где установлен роутер.
- Подождать некоторое время, не исчезнет ли неисправность сама. Для роутеров
доступа достаточным является 5 - 15 минут; базовые роутеры должны восстанавливаться,
если они перевызвались сами, за 3 - 5 минут;
- Сделать запись в журнале роутера о предпринимаемых мерах.
- Перевызвать роутер по RESET или питанием, если это возможно и не удается
найти специалистов. Роутеры доступа можно перевызывать без специалистов,
если их не удалось быстро найти; базовые роутеры перевызываются вручную
только если ничего другого не помогает.
- Если после перевызова все заработало нормально, сделать запись в журнале;
если перевызов не помог, сделать комментарий к событию и искать специалистов.
- Если действия по пунктам 1 - 3 показывают противоречивую картину (непонятно,
работает ли роутер на самом деле), то сделать запись в журнале и ориентироваться
по жалобам клиентов.
- Если отказ роутера вызван неустранимыми причинами, создать комментарий
к аварии, описывающий эти причины и примерное время восстановления.
В случае отказов части сети комментировать нужно отказавшие элементы,
а не те объекты, которые стали недоступны в результате отказа.
4.2. Авария канала.
В отличие от аварий роутеров, при аварии каналов есть высокая вероятность
аварии физической среды или канального оборудования, и намного меньше вероятность
ложной аварии. Кроме того, каналов, жизненно важных для бесперебойной работы
базовой сети, совсем немного. Поэтому регламент обслуживания аварии канала
сильно отличается от регламента аварии роутера:
- Убедиться в том, что данный канал находится в нашей компетенции и обслуживается
нами. Признаком этого является наличие карточки канала.
- Посмотреть состояние интерфейса на роутере, нажав на имя интерфейса
на мониторе. [это возможно не на всех роутерах]. Результат команды
выглядит примерно так
Serial1 is up, line protocol is down
Hardware is HD64570
Description: KAZNA via COMBELLGA 64K
Internet address is 193.124.255.121/30
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
Last input 7w1d, output 00:00:04, output hang never Last clearing of "show interface" counters never
Input queue: 0/75/0 (size/max/drops); Total output drops: 0
Queueing strategy: weighted fair
Output queue: 0/64/0 (size/threshold/drops)
Conversations 0/2 (active/max active)
Reserved Conversations 0/0 (allocated/max allocated)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
73320 packets input, 4229371 bytes, 0 no buffer Received 72505 broadcasts, 0 runts, 0 giants
8 input errors, 8 CRC, 0 frame, 0 overrun, 0 ignored, 7 abort
457964 packets output, 12416726 bytes, 0 underruns
0 output errors, 0 collisions, 141534 interface resets
0 output buffer failures, 0 output buffers swapped out
2 carrier transitions
DCD= up DSR= up DTR= up RTS= up CTS= down
Здесь содержится следующая информация:
- Serial1 is up, - на канале есть сигнал несущей, или по крайней
мере модем выдает такой сигнал. Возможные состояния в этом месте такие:
- UP - есть несущая
- DOWN - нет несущей,
- ADMINISTRATIVELY DOWN - канал выключен в конфигурации.
- line protocol is down - состояние протокола обмена информацией между
роутерами по каналу. Интересно, если предыдушее состояние - UP. Возможные
значения:
- up - либо роутеры на разных концах видят друг друга, либо на канале
выключен контроль соединения (например, в нижней строке написано keepalive
unset).
- down - роутеры не видят друг друга, самая вероятная причина - нет соединения
по каналу (завис модем), несогласованные протоколы, плохой канал.
- up (looped) - на канале установлен заворот сам на себя, обычно это
происходит при тестировании и наладке.
- up (spoofed) - система изображает для всех, что канал работает, но
на самом деле по каким то причинам соединения нет (это возможно для телефонных
и ISDN соединений, которые устанавливаются только когда есть что передавать).
- Internet address is 193.124.255.121/30 - адрес на интерфейсе
(.30 означает что всего выделено 4 адреса, из которых 2 - используются
для концов канала);
- 5 minute input rate 0 bits/sec, 0 packets/sec - скорость работы
на ввод.
- 5 minute output rate 0 bits/sec, 0 packets/sec - скорость работы
на вывод.
- 73320 packets input, 4229371 bytes, 0 no buffer - число принятых
пакетов.
- 457964 packets output, 12416726 bytes, 0 underruns - число посланных
пакетов.
- 8 input errors, 8 CRC, 0 frame, 0 overrun, 0 ignored, 7 abort -
число пакетов принятых с ошибкой (ошибки приема)
- DCD= up DSR= up DTR= up RTS= up CTS= down - модемные сигналы,
в том числе
- DCD - наличие несущей
- DSR - готовность модема к работе
- DTR - up - роутер просит модем включиться, down - просит модем выключиться
(линия не должна работать
- RTS = up - роутер готов принимать данные
- CTS = up - модем готов принимать данные, down - не готов принимать
данные (например, пытается пропихнуть их в плохую линию).
- Вместо последней строки, возможна такая выдача:
Timeslot(s) Used:13, Transmitter delay is 0 flags
^^^^^^^^^^^^^^^^^ - таймслоты в канале 3 мегабита, которые занимает данный
клиент (при общении с операторами GL - это те номера, которые у них идут
подряд и нарисованы над каналом сверху, а не снизу).
- Определить причину аварии, и получить подтверждение аварии. Причиной
состояния АВАРИЯ могут быть:
- Ошибки по входу или выходу интерфейса. Ошибки показаны на мониторинге
красной чертой. Ошибки в несколько процентов не являются поводом для беспокойства,
ошибки на совсем пустом канале (зеленая линия совсем короткая) тоже не
всегда о чем то говорят, ошибки на выходном канале на PC роутере являются
ошибкой первой версии монитора (точнее6 свойством PC роутера). В этих случаях
никакой реакции не нужно, если только нет жалоб клиента. В случае большого
процента ошибок на сильно загруженном канале, идущих по _входу_ (верхняя
черта) желательно провести проверку линии.
- Падение физического канала - состояние на мониторинге DOWN, и в ряде
случаев (если пропала несущая на модеме) на распечатке интерфейса будет
указано SerialXXX is down - канал в DOWN, нет несущей. Можно принимать
меры.
- Состояние физического канала не контролируется модемом либо он в порядке,
но роутеры на концах канала не видят один другого (line protocol - down).
Это может быть ошибкой канала, а может быть результатом плохой конфигурации
(впрочем, второе встречается намного реже первого). Можно принимать меры.
- Канал выключен административно в конфигурации роутера (administratively
down) - нужно записать в журнал и повесить на канал соответствующий комментарий.
- Канал перенесен или переключен на другое место. Косвенным признаком
может служить возможность пинговать (проверять доступность) дальнего конца
канала при аварийном его состоянии в мониторинге. При этом возможно как
состояние administratively down, так и состояние (down) говорящее, что
канал отключен от модема (при этом и DSR, и CTS будут в DOWN).
- Для тех каналов, которые поддерживаются операторами RELCOM, и в тех
случаях, когда получено подтверждение аварии от персонала NOC либо LINKS
(либо авария произошла вне каких либо системных работ, или звонит клиент)
нужно предпринять активные меры. Они зависят от типа канала и описываются
конкретно по каждому типу канала, по умолчанию это:
- Для аналоговых каналов - сброс модема, проверка линии в ЛАЦ.
- Для цифровых дальних каналов - запрос в Ростелекомм (или к провайдеру
канала), при этом важно знать название канала;
- Для цифровых составных каналов - это попытка выяснить у провайдера
канала, нет ли у него аварии, и инициировать дополнительную проверку;
- Для местных цифровых каналов, приходящих по потоку (например каналы
Golden Line) это - дополнительная проверка канала в GL (нужно знать номер,
целесообразно сравнить имя клиента у них и у нас и сравнить номера слотов
в карточке и в распечатке монитора). В тех случаях, когда оговорено активное
сопровождение (то есть клиент получил обещание оперативно устранять неисправности
нашими силами), а также в прочих случаях наладки цифровых каналов, порядок
действий обычно такой (он зависит от провайдера, от опыта их оператора,
от множества других факторов):
- Выясняется, нет ли тяжелых аварий у провайдера, если есть - записывается
комментарий в журнал;
- Запрашивается у провайдера дополнительная проверка.
- Если есть подозрение, что клиент мог выключить оборудование, и нет
запроса от клиента, можно считать, что клиент выключает свое оборудование,
и больше с каналом не работать. Если есть необходимость наладить канал,
можно проверить его работу (например у GL) попросив поставить тестовые
завороты - если после этого в мониторе появляется состояние LOOP, и соответственно
в выдаче про интерфейс - Line Protocol up(looped) - тогда канал от нас
до GL работает нормально и проблема где то дальше (скорее всего, у клиента),
если не появляется - то либо на канале использован экзотический протокол,
либо проблема между нами и GL. В любом случае после проверок нужно попросить
вернуть канал в нормальное состояние.
- По результатам пункта (3) пишется комментарий или (если все встало)
запись в журнал канала.
- Как правило, каналы приходящие по сложным трассам проверяются сотрудниками
LINKS или NOC. Общий принцип таких проверок такой:
- Работает ли интерфейс на нашем конце (если он стоит в admin down, нужно
искать административную, а не техническую причину; очень вероятна ошибка
конфигурации базы роутинга);
- Видим ли мы ближнего провайдера каналали. Для этого у него ставится
заворот, если мы не видим - проблемы между нами и этим провайдером, если
видим - дальше;
- Видим ли мы следующего провайдера канала (аналогично - ставятся завороты).
- Аналогичные проверки ведутся с другой стороны.
В нормальных условиях все эти проверки ведет персонал LINKS или NOC
при наладке канала.
- В любом случае в результате работы должно быть получено:
- Запись в журнал - комментарий к событию;
- Статус события, описывающий его состояние с учетом имеющейся информации;
- Если у канала есть провайдер с дежурным - дежурный должен быть информирован
о _возможной аварии_;
- Если канал относится к важным, должны быть информированы группы LINKS
и NOC.
Приложения. Регламенты.
Схема составления регламента такова:
- Обшая характеристика провайдера и тип каналов, которые он делает;
- Именование каналов у провайдера;
- Возможности провайдера по наладке и проверке каналов.
- Контактные телефоны и вспомогательная информация;
- Порядок контактов и обслуживания упавших каналов.
- Дополнительная информация.
1. Регламент работы с аналоговыми каналами на M9;
2. Регламент работы с каналами Golden Line;
3. Регламент работы с каналами SovIntel;
4. Регламент работы с внутренними каналами Ростелеком.
5. Регламент работы с внешними каналами Ростелеком.
6. Регламент работы с каналами RBnet, и с распределенной локальной
сетью nmbb-*.