Оптические сети : Synchronous Optical NETwork (SONET)

Триггеры SONET

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Спусковой механизм является любым событием, которое выполняет роль причины в причинно-следственном отношении в интерфейсе SynchronousOptical Network (SONET) (синхронная оптоволоконная сеть) в IOS. Иногда, можно использовать команду pos delay triggers. В других случаях, когда вы пытаетесь встретить трудные Соглашения об уровне обслуживания (SLA), Cisco рекомендует не использовать команду pos delay triggers, особенно. Поставщики услуг продают дифференцируемые уровни обслуживания на основе определенных, некоторый соглашений. Соглашение о соглашениях с тем, как сеть внутренне направляет, защищает или располагает по приоритетам трафик абонента. Эти команды помогают поставщикам настраивать сети для совещания соглашений о предоставлении услуг.

Этот документ исследует спусковые механизмы, которые относятся для установления связи вверх и вниз по событиям. Этот документ также объясняет, как развернуть Передачу пакета по сети SONET (POS) и рассматривает SLA и времена согласования на Уровне 3.

Предварительные условия

Требования

Для этого документа отсутствуют особые требования.

Используемые компоненты

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

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Условные обозначения технических терминов Cisco.

События, которые Переводят Интерфейс пакетной передачи POS (по сети Sonet) в нерабочее состояние

В этом разделе описываются события, которые переводят Интерфейс пакетной передачи POS (по сети Sonet) в нерабочее состояние, и перечисляет связанные команды.

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

Список спусковых механизмов в этом разделе обращается к Системам транспортировки SynchronousOptical Network (SONET) (синхронная оптоволоконная сеть) GR-253-CORE: Общая спецификация Общих критериев:

  • Потеря сигнала раздела (SLOS) — спецификация указывает, что необходимо обнаружить не меньше, чем 2.5us, и не больше, чем 100us (6.2.1.1.1).

  • Потеря фрейма раздела (SLOF) — спецификация указывает, что необходимо обнаружить это в минимуме 3 мс (или 24 последовательных ошибочных скороговорки формирования кадров) (6.2.1.1.2).

  • Сигнал индикации аварийного состояния - Линия (AIS-L) — AIS-L должна быть отослана в надлежащих случаях в 125 мкс обнаружения. Устройство должно обнаружить получение AIS-L, если устройство видит 5 последовательных фреймов, где биты 6,7, и 8 из K2 установлены в 111 (6.2.1.2.1).

  • Частота появления ошибочных битов при деградации сигнала (SD-BER) — SD-BER является спусковым механизмом только на интерфейсах с Автоматическим переключением на резерв (APS) (связанный к вычислению значений BER B2).

  • Уровень ошибок в канале связи Пропадания сигнала (SF-BER) — SF-BER является спусковым механизмом и для APS и для интерфейсов не-APS (связанный к вычислению значений BER B2).

  • Удаленная Дефектная Индикация - Линия (RDI-L) — RDI-L не является спусковым механизмом для POS или APS. (Однако RDI-L является спусковым механизмом для FRR MPLS) (разделите 5.3.3.1).

Для получения дополнительной информации о разделах, упомянутых в этом списке, посмотрите leavingcisco.comвеб - узлы/URL информационного гипермаркета Telcordia.

Связанные команды

Линия pos delay triggers n команда удерживает LOS/LOF/AIS для n мс, прежде чем команда вызовет линию вниз:

При настройке команды без какого-либо целочисленного значения время задержки составляет 100 мс по умолчанию. Можно использовать Линию, включает любой Интерфейс пакетной передачи POS (по сети Sonet) не-APS. Вы не можете использовать Линию, включает интерфейсы, которые участвуют в APS, потому что спусковые механизмы Линии вмешиваются в работу APS. Линия pos delay triggers n команда не позволяет линии выключаться на кратком LOS, который прибывает из внутренне защищенного механизма Плотного спектрального мультиплексирования (DWDM) со времени происходит, внутренний защитный коммутатор DWDM. Если дефект очищается во время периода удержания, он походит на дефект, никогда не происходил.

Команда pos delay triggers line удерживает любое действие на основе дефекта (кроме инкрементно увеличить дефектный счетчик), пока не заканчивается указанный период удержания.

Если вы не выполняете эту команду, APS и связываетесь вниз от вышеупомянутых дефектов SONET, сразу вызваны в Процессоре маршрута (RP).

Спусковые механизмы пути

Эти определенные дефекты Уровня тракта инициируют изменение состояния, только если вы включили путь триггеров задержки POS на интерфейсе:

  • AIS-P — Этот дефект должен быть повышен в 125 мкс от обнаружения дефекта, который приводит к AIS-P. Когда H1 и байты H2 для пути STS содержат всю 1 с для 3 последовательных фреймов, Path Terminating Equipment (PTE) должен обнаружить этот дефект. Связанные пути должны наблюдать только первый H1 и байты H2. Для получения дополнительной информации посмотрите раздел 6.2.1.2.2 из R6-175 и R6-176.

  • RDI-P — Если RDI-P присутствует, дефект, должен быть обнаружен в 10 кадрах. См. 6.2.1.3.2 из R6-221.

  • B3-TCA (Threshold Crossing Alarms) для B3 — Этот сигнал тревоги связан к Бинарным синхронным связям B3 (BiSync (двоичная синхронная передача данных)) IP (BIP) вычисление.

  • LOP-P (Потеря пути Указателя) (если версия IOS включает CSCdx58021) — Видит раздел 6.2.1.1.3 из GR-253.

Для получения дополнительной информации о разделах, упомянутых в этом списке, посмотрите leavingcisco.comвеб - узлы/URL информационного гипермаркета Telcordia.

Связанная команда

Команда <msec> пути триггеров задержки POS включает выключение канала, включающее AIS-P, RDI-P и чрезмерные ошибки B3. По умолчанию вызов выключения канала для ошибок пути отключен.

Команда также задает время рассинхронизации в диапазоне от 0 до 511 мс (по умолчанию составляет 100 мс). Дефекты спускового механизма пути (AIS-P, RDI-P), что ясный перед концом периода удержания не вызывают вызов. Если дефекты Уровня тракта обработаны, когда вы явно не настроили эту команду на Интерфейсе пакетной передачи POS (по сети Sonet), никакие результаты действия. В отличие от спусковых механизмов Линии, интерфейсы APS позволяют спусковые механизмы Пути, потому что спусковые механизмы Пути не вмешиваются в действие линейного уровня APS. Спусковым механизмам пути не позволили быть настроенными с APS в версиях ранее, чем Cisco Выпуск ПО IOS� 12.0 (28) S. Спусковые механизмы пути были добавлены для ускорения соединения / вниз поведение Интерфейсов пакетной передачи POS (по сети Sonet), когда связано с сетями SONET. Эта позволенная более быстрая конвергенция Уровня 3 в присутствии удаленных ошибок.

Сводка поведения CLI триггеров POS

Эта таблица приводит условия спусковых механизмов POS и cвязанные результаты:

Условие Результат
Если вы не настроили ничто явно отнесенное к спусковым механизмам POS. Спусковые механизмы линейного уровня сразу обработаны.
Если вы настроили команду pos delay triggers line. Спусковые механизмы линейного уровня обработаны после задержки 100 мс.
Если вы настроили линию pos delay triggers x команда. Спусковые механизмы линейного уровня обработаны после x мсек, где x между 0 и 511.
Если вы не настроили ничто явно отнесенное для Соединения каналом спусковых механизмов. Спусковые механизмы пути не обработаны и не вызовут действия для исполнения.
Если вы настроили команду пути триггеров задержки POS. Триггеры уровня маршрута обработаны после задержки 100 мс.
Если вы настроили путь триггеров задержки POS x команда. Триггеры уровня маршрута обработаны после x мсек, где x между 0 и 511.

Debouncing сигналов оповещения SONET

Сигналы оповещения SONET, которые следуют из дефектов, проводятся в течение 10 секунд (10.5 +-.5) после того, как очищается дефект.

Дефектная обработка

В IOS карты POS изменяют свое Состояние линии из-за других спусковых механизмов через два общих средства для дефектной обработки. В то время как это зависит от определенной конфигурации интерфейса (APS или не-APS), в целом существует два типа сбоев:

  • Управляемый

  • Неуправляемый

Необходимо понять сроки, определенные для обработки сигнала тревоги, которую использует этот документ:

  • Дефект — неисправное состояние, которое распознают аппаратные средства.

  • Сбой — дефект, который впитали для требуемого ~2.5sec, и затем сообщают через сообщения SONET-4-ALARM. Любой дефект, который является спусковым механизмом, не промокает.

  • Неуправляемые ошибки — События, такие как LOS, LOF, и т.д. Они обнаружены Средством формирования кадров SONET определенным набором параметров и не требуют никакого вычисления. Существует или дефектный подарок и утверждал аппаратными средствами, или нет никакого дефекта. Серьезные отказы, такие как они, в целом, обрабатываются через прерывания. LOS, LOF, AIS-L, и в особых случаях, AIS-P и RDI-P сразу утверждаются. Они зависят от станка для заделки крепи и определенных правил обнаружить каждый из этих дефектов. Эффект этих дефектов непосредственен. Однако можно дать маршрутизатору команду задерживать утверждение этого дефекта как сбой. Существует два таймеров, которые определяют значение задержки, pos delay triggers [путь | линия] и задержка носителя. Они обращены позже в документе.

  • Управляемые сигналы тревоги — События, такие как TCA и вычисления SD/SF-BER. Они требуют, чтобы некоторое вычисление определило, присутствуют ли они, находятся на увеличении или уменьшении, и т.д. Например, у вас не может быть LOS, который увеличивает его “LOS” с точки зрения маршрутизатора. Однако у вас может быть BER, который находится на увеличении или уменьшении; принятые меры могут быть другими. Смягченные отказы, как BER и TCA, требуют некоторого вычисления, потому что они зависят в ряде факторов, например, пороги, которые пользователь может настроить, битовая скорость и максимальное число CV BIP (потому что они являются другими для B1, B2 и B3). Эти сбои также занимают больше времени, чтобы быть обнаруженными, потому что аппаратные средства опрошены для счетчиков BIP, и также потому что эти типы дефектов постепенны в природе и накопленные в течение долгого времени. Это также истинно, что в целом вы не идете от 0 BIP прямо к ухудшению качества сигнала (SD) или пропаданию сигнала (SF) без другого типа подарка серьезного отказа в сети. Эти дефекты медленнее для появления когда по сравнению с серьезными отказами.

Вот обобщенный подход к основным вычислениям, который описывает, как вычислить BER:

После каждого перезапуска вычислений и пока BER_Period не достигает Required_BER_Period (окно интеграции не полностью развернуто), алгоритм функционирует строго как интеграция или усреднение того:

  • BER_Period = BER_Period + 1 сек.

  • Current_BIP = Current_BIP + BIP_new.

  • Current_BER = Current_BIP/BER_Period.

После того, как BER_Period достигает Required_BER_Period (окно интеграции было полностью развернуто и начинает скользить), функции алгоритма как алгоритм дырявое ведро один:

  • BER_Period = Required_BER_Period.

  • Current_BIP = Current_BIP + BIP_new - Current_BER * 1 сек.

  • Current_BER = Current_BIP/BER_Period.

Required_BER_Period определен на основе только скорости линии и настроенной пороговой величины BER, после стандартов (См. рисунок 5-5, Критерии времени Инициирования Коммутатора, GR-253). Однако это ниже ограничено 1 секундой, нашей частотой отсчетов.

Таким образом BER_Period (окно интеграции) шаги с каждым опросом и новый BER вычислен с каждым опросом. Если Current_BER когда-нибудь по определенному пределу, мы сразу повышаем соответствующий дефект во время того же самого опроса или интервала расчета, и поддерживаем ответ минимальным. Мы повторяем эти вычисления каждую секунду и проверку, чтобы видеть, имело ли одно из трех событий место:

  • BER все еще находится в пределах того же самого диапазона. Нет никакого нового действия.

  • BER увеличился снова и пересек SD или SF порог (для B2). Выдайте новый аварийный сигнал.

  • BER уменьшился ниже пороговой величины BER. Очистите сигнал тревоги.

Для утверждения TCA или SD/SF, необходимо ждать только, пока вы не пересекли предел в том соответствующем интервале опроса. Во время вычисления проверьте, пересек ли Current_BER порог, и если это имеет, можно идти вперед и сразу утверждать сигнал тревоги через программное обеспечение.

Это допустимо, потому что, если Current_BER является достаточно большим для вызова сигнала тревоги первоначально, условие все еще истинно в конце BER_Period. Это основывается, как значения определены и сравнены относительно окна расчета.

При очистке сигнала тревоги необходимо ждать до конца окна расчета BER_Period. Это должно гарантировать, что никакие новые BIP не накоплены во время последней части окна, которое могло бы поддержать вас выше порога.

Примечание: Согласно GR-253, SD-BER и SF-BER оба связаны строго к количеству BIP B2. Текущие пороговые значения по умолчанию:

  • Пороговые величины BER — SF = 10e-3 SD = 10e-6

  • Пороговые значения TCA — B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

Карты Примечание: Engine2 OC-48 имеют эти пороги по умолчанию:

  • Пороговые величины BER — SF = 10e-4 SD = 10e-6

  • Пороговые значения TCA — B1 = 10e-6 B2 = 10e-6 B3 = 10e-6

Если вы хотите иметь действие спускового механизма Пути TCA B3, подобное SF, порог B3 должен быть записан в тот же порог, 10e-3. Можно сделать так посредством команды pos threshold b3-tca 3 в приглашении router(config-if)#.

Примечание: Поскольку интервал опроса является одной секундой, которая является минимальным временем, в которое мы будем когда-либо замечать и повышать дефект SD/SF или TCA. Кроме того, из-за накопленной природы TCA/SD/SF, эти типы сбоев сопровождаются некоторым другим сбоем, когда они происходят быстро в типичных неисправностях. Это сохраняет равновесие между использованием процессора маршрутизатора и производительностью. Интервал опроса не может быть настроен.

Спусковые механизмы в действии

Этот раздел предоставляет некоторые общие сведения для исследования взаимодействия некоторых различных настраиваемых кнопок в IOS:

Команда pos delay triggers [line | path] кратко задерживает создание отчетов и действие дефекта.

POS линия триггера задержки является временем удержания прежде, чем реагировать на сигнал тревоги линии. По умолчанию является немедленной реакцией, что означает, что триггер задержки pos выравнивает 0 . Если вы непосредственно настраиваете линию триггера задержки pos без значения, то значение по умолчанию 100 мс принято во внимание. Это обеспечивает непосредственное или задержанного ответ, на основе нужного эффекта. С любым из них настроенных, дефект не обнаруживается как активный сигнал тревоги, пока период удержания не закончен.

Шкала времени:

|----------|----------|----------|----------|----------|
T0         T1         T2         T3         T4         T5

Здесь:

  • t0 — Время, когда происходит дефект.

  • t1, когда аппаратные средства обнаруживают дефект.

  • t2 — Время, когда о дефекте сообщают как сбой.

  • t2-t3 — Время, которое удержано для любых настроенных спусковых механизмов.

  • t3-t4 — время, которого вы ждете из-за задержки носителя.

  • t4 — время, когда интерфейс фактически снижается в IOS.

  • t5 — Время, в которое снижается любая смежность для протокола маршрутизации.

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

Команда post delay triggers влияет на продолжительность между t2 и t3, и в действительности, скрывает дефект от IOS, пока период удержания не закончен. Конечно, если дефект очищен перед достижением t3 ничто не происходит, и это - как будто ничто не произошло. Значение по умолчанию и для линии и для спусковых механизмов Пути составляет 100 мс, и диапазон от 0 до 511 мс. Спусковые механизмы пути не включены (другими словами, они не принимают мер), пока сначала не настроен путь триггеров задержки POS. на месте продажи путь триггера задержки является временем удержания прежде, чем реагировать на аварийный сигнал пути. По умолчанию не является никакой реакцией. Если вы непосредственно настроите путь триггера задержки pos без значения, то значение по умолчанию 100 мс будет назначено автоматически. Это включает AIS-P, RDI-P и B3-TCA. Эта функциональность была добавлена через CSCds82814 (приблизительно 12.0 (15.5) S/ST).

Carrier-delay является временем удержания между концом времени удержания задержки POS, и это переведет интерфейс IOS в нерабочее состояние. По умолчанию составляет 2000 мс. Задержка носителя является временем между t3 (когда IOS узнает сбой), и t4 (когда интерфейс выключается). По умолчанию это установлено в 2 секунды и может быть настроено для значений msec. Как шкала времени указывает, это - аддитивная функция поверх таймеров занятости уровня SONET. Это ведет себя таким же образом как спусковые механизмы POS – если сигнал тревоги очищается перед концом периода удержания не переведен в нерабочее состояние интерфейс. Однако здесь существует загадка. Таймер устранения дрожания SONET не очищает дефект, прежде чем задержка носителя активирует, пока задержка носителя не является большой (хорошо более чем 10 секунд). Это приводит к ситуации, где задержка носителя почти всегда активируется, и поэтому, как должны полагать, является довольно маленькой, когда развернуто с Интерфейсами пакетной передачи POS (по сети Sonet). Задержка носителя также добавлена после того, как сигнал тревоги очищен, прежде чем интерфейс объявлен также. Следовательно, можно посчитать значение задержки носителя дважды, прежде чем интерфейс возвратится.

С некоторыми интерфейсами и физическими средствами связи это полезно. Однако с Интерфейсами пакетной передачи POS (по сети Sonet) существует много спусковых механизмов и таймеров, которые можно использовать, и объединенный для создания нужного эффекта, без задержки носителя, берущей такое решающее значение. Значение задержки носителя 0-8 мс является хорошей отправной точкой для клиентов для рассмотрения, когда они тестируют эти кнопки самостоятельно. В целом хорошая стратегия состоит в том, чтобы использовать команду pos delay triggers, чтобы поглотить любые проблемы и предоставить требуемый эффект рассинхронизации. Задержка носителя может быть сохранена маленькой для уменьшения ее влияния.

Упомянутый выше таймер устранения дрожания SONET установлен в 10 секунд (+/-.5sec) и требуется GR-253 гарантировать, что не происходит период откидной створки меньше чем 10 секунд. Таймер запускается после того, как дефект очищен. Таймер перезагружен, если другое дефектное событие имеет место, прежде чем окно таймера истекло.

Шкала времени:

|----------|----------|----------|----------|----------|---------|
T0         T1         T2         T3         T4         T5        T6

Здесь:

  • t0 — Дефект очищается.

  • t0 — Таймер устранения дребезжания запускается.

  • t4 — t0 + 10 сек. (следовательно, сбой должен очиститься, если никакие новые дефекты не происходят между t0 и t4).

Если событие имеет место перед t4, (SAID) в t2 (это мог бы быть другой дефект или повторное происхождение того же типа дефекта), остановлен таймер, пока этот новый дефект не очищен. Когда нет никаких активных дефектов и количества в течение этих ~10 секунд, в t3 таймер запускается снова. Если ни с какими новыми событиями не встречаются, очистите сигнал тревоги в t5, и затем запустите таймер задержки носителя. Когда задержка носителя будет очищена в t6, переведите интерфейс в рабочее состояние снова.

Эта информация должна позволить клиенту понимать более ясно, как Интерфейсы пакетной передачи POS (по сети Sonet) реагируют на различные условия SONET/SDH. Это позволяет оборудованию быть настроенным более точно согласно предполагаемому поведению клиента.

Почему использование вызывает?

Этот раздел объясняет, когда необходимо использовать команду pos delay triggers [line | path], и когда вы не должны использовать его.

Когда вы не должны использовать pos delay triggers, вот сценарии. Существует несколько сценариев:

  • Вы не можете использовать спусковые механизмы линии с настраиваемыми интерфейсами APS. Версии ранее, чем программное обеспечение Cisco IOS версии 12.0(28)S не позволяли даже использование спусковых механизмов Пути.

  • Когда вы явно не хотите, чтобы дефекты Уровня тракта перевели интерфейс в нерабочее состояние, вы не можете использовать эти спусковые механизмы.

  • Когда вы хотите, чтобы спусковые механизмы линейного уровня перевели интерфейс в нерабочее состояние без задержки, вы не можете использовать эту команду.

Когда можно использовать команду pos delay triggers, вот сценарии:

  • Когда вы хотите удержать эффект дефекта линейного уровня временно.

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

  • Позволять дефектам Уровня тракта перевести интерфейс в нерабочее состояние, но с некоторой включенной рассинхронизацией.

SLA и POS вызывают

Исследуйте эту шкалу времени:

|----------|--------------------|
T0         T1                   T2
  • Время t=0 (t0) — Когда обнаружен дефект.

  • Время t2 — требуемое время восстановления SLA.

  • T1 времени — Любая рассинхронизация от команды pos delay triggers, которая настроена (по умолчанию для ЛИНИИ 0 и по умолчанию для ПУТИ, не включена).

  • X значение рассинхронизации (так X = значение t1).

  • Y является временем, это возьмет Уровень 3 для восстановления сервиса.

Теорема

Иногда, можно использовать команду pos delay triggers, в то время как в других случаях, вы не можете, особенно когда вы пытаетесь встретить трудные Соглашения об уровне обслуживания (SLA).

Постулаты

  • Если Y> (t2-t1) для значения t1, рассинхронизация не является хорошей идеей, потому что, вы не можете встретить SLA при настройке какой-либо рассинхронизации.

  • Если Y <= (t2-t1), можно рассмотреть реализацию рассинхронизации. Если продолжительность сбоя является меньше, чем (t1-t0), можно удержать, потому что, вы не должны использовать ресурсы маршрутизатора, и можно встретить требуемый SLA. Если дефект сохраняет в прошлый раз t1, можно все еще встретить SLA, даже при том, что вы теряете некоторое время перед инициированием восстановления на уровне IP.

У вас должно быть некоторое знание о сети базовой передачи, и времена согласования сети Уровня 3, для знания значений, которые можно использовать в этих формулах. Также необходимо выполнить некоторое тестирование.

Вот то, как работают спусковые механизмы:

  • Линия pos delay triggers n команда удерживает LOS/LOF/AIS для n мс перед линией спусковых механизмов команды вниз. Значение по умолчанию составляет 100 мс. Можно использовать эту команду на любом Интерфейсе пакетной передачи POS (по сети Sonet) не-APS. Линия pos delay triggers n команда не позволяет линии выключаться на кратком LOS, который прибывает из внутренне защищенного механизма DWDM со времени происходит, внутренний защитный коммутатор DWDM. Если дефект очищается во время периода удержания, он походит на дефект, никогда не происходил.

  • Команда pos delay triggers line удержит любое действие на основе дефекта (кроме инкрементно увеличить дефектный счетчик), пока не закончится указанный период удержания.

    Если вы не выполняете эту команду, APS и ссылка вниз сразу вызваны в RP.

Развертывания спусковых механизмов SONET

В этом разделе описываются развертывания спусковых механизмов SONET.

Защищенная сеть SONET: никакой APS на маршрутизаторах

Рисунок 1 – внутренне защищенная сеть SONET

/image/gif/paws/62622/K1.gif

Сеть SONET имеет внутреннюю защиту, что означает, что сбой в сети SONET вызывает некоторый защитный коммутатор для восстановления сервиса очень быстро. Поэтому необходимо рассмотреть, хотите ли вы перевести интерфейс в нерабочее состояние и уведомить Уровень 3. В большинстве случаев, когда защитный коммутатор происходит в сети SONET, маршрутизаторы видят краткую линию или соединяют AIS каналом, в то время как сеть берет действие по восстановлению. Однако это происходит, только если сбой является одним переходом далеко от любого маршрутизатора. Сеть SONET может возможно быть несколькими NE в диаметре, любой маршрутизатор рассматривает сбои ЛИНИИ только как Ошибки пути. В этом случае рассмотрите путь и спусковые механизмы линейного уровня, если вы хотите рассинхронизацию.

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

  • Сеть сходится достаточно быстро? В противном случае этот подход не подходит.

  • Каково влияние маршрутизации вокруг такого сбоя? Действительно ли влияние является столь большим на маршрутизаторе что снижения производительности ниже допустимого уровня?

В конечном счете необходимо решить, можно ли проигнорировать потенциал ~60msec соответствие, или предпочитаете ли вы направлять вокруг такого события. Если можно проигнорировать соответствие, необходимо определить, сколько из “выдумки разлагает на множители” для включения, потому что, вы не хотите удерживать на этом дефекте только, чтобы ждать несколько миллисекунд лишь немногие, и таким образом задержать корректирующее действие.

В этом сценарии линия pos delay triggers и путь, вероятно, достаточны. Кроме того, рассмотрите значения по крайней мере 60 мс, если гарантирована рассинхронизация. Если сеть достаточно широка, и вы хотите незамедлительно принять меры и на линейном уровне и на дефектах уровня тракта, вы не должны настраивать спусковые механизмы линейного уровня. Однако необходимо настроить путь триггеров задержки POS со значением 0 для включения немедленной обработки дефектов Уровня тракта.

Внутренне незащищенная сеть SONET

Рисунок 2 – внутренне незащищенная сеть SONET

/image/gif/paws/62622/K1.gif

В незащищенной сети SONET вы еще выполняете те же риски как в первом сценарии, плюс некоторые. Если сеть является достаточно большой, маршрутизаторы никогда не могут потенциально видеть дефект Линейного уровня в случае сбоя, потому что все фильтрованы дефекты. Маршрутизаторы видят дефекты Уровня тракта вверх и вниз по потоку. Таким образом, в некоторых ситуациях, где сбой происходит в сети, маршрутизатор только видит События уровня пути, и между маршрутизаторами нет никакой сквозной непрерывности. Еще хуже, никакое восстановление не происходит на Уровне SONET для исправления этой ситуации.

В этом сценарии необходимо настроить спусковые механизмы Пути просто, чтобы позволить маршрутизаторам с обоих концов принимать меры, когда маршрутизаторы встречаются с дефектом ПУТИ, даже если маршрутизаторы не хотят эффекта рассинхронизации. Когда у вас есть спусковые механизмы настроенного пути как оператор сети, необходимо проверить, лучше ли удержать или вызвать восстановление Уровня 3.

Защищенная или незащищенная сеть SONET

Рисунок 3 – внутренне незащищенная сеть SONET

/image/gif/paws/62622/K2.gif

В программном обеспечении Cisco IOS версии 12.0(28)S можно включить ПУТЬ, включает каналы APS. При развертывании APS на локальной переменной или удаленных маршрутизаторах коммутатор APS вызывает удаленную Работу, и Защитите маршрутизаторы для наблюдения краткого дефекта Уровня тракта. С маленьким значением спускового механизма выключаются интерфейсы, и эта ситуация не выбираема. Интерфейс, который выключается восстановление сервиса задержек, которое уже происходит. Кратковременный сбой, который происходит в облаке, может также задержать сервисное восстановление. Однако возникновение повторяющейся ошибки уровня пути указывает, что защита схем (или в сети, или на дальнем конце) была неспособна восстановить подключение. В этом случае маршрутизаторы APS должны принять меры и инициировать повторное схождение маршрутизации. Можно настроить значения задержки спускового механизма Пути> = 100 мс. С этой конфигурацией, когда повторяющаяся ошибка происходит или в сети SONET или в удаленном конце, маршрутизаторы приносят оба интерфейса APS к состоянию ссылки вниз. Поэтому маршрутизаторы инициируют более быстрое перенаправление и восстановление сервиса.

Защищенная сеть DWDM

Рисунок 4 – защищенная сеть DWDM

K3.gif

В этом сценарии мы не должны использовать спусковые механизмы Пути, потому что сеть DWDM не участвует на уровне Протокола SONET. Маршрутизатор обнаруживает любой сбой в РАЗДЕЛЕ или Линейном уровне.

Снова, потому что сеть DWDM внутренне защищена, сбой, внутренний к восстановлению сети, чтобы скоро произойти. Маршрутизатор, как правило, видит очень краткий LOS, LOF или пакет Ошибок BIP.

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

Команда pos delay triggers line достаточна в этой ситуации при выборе задержки.

Незащищенная сеть DWDM

Рисунок 5 – незащищенная сеть DWDM

K4.gif

С незащищенной сетью DWDM в транспорте необходимо обратиться к любому сбою в маршрутизаторах. В этой ситуации конфигурация по умолчанию обеспечила бы мгновенный ответ к любым сбоям, замеченным в любом маршрутизаторе, потому что DWDM не участвует в Протоколе SONET. Если вы требуете этого эффекта, конфигурация по умолчанию никаких настроенных спусковых механизмов POS является соответствующей.

При требовании некоторой рассинхронизации команда pos delay triggers line достаточна для обеспечения этой функциональности.

Маршрутизаторы, связанные встречно-параллельный

Рисунок 6 – маршрутизаторы, связанные встречно-параллельный

K5.gif

Два маршрутизатора соединились, back-to-назад между двумя Интерфейсами пакетной передачи POS (по сети Sonet) должен работать точно так же, как последний сценарий. Вы сразу видите сбои или в маршрутизаторе, потому что нет никакого промежуточного оборудования, которое воздействует на Служебную информацию Sonet или завершает любую часть сигнала Уровня SONET.

Содержательная ситуация состоит в том, когда R1 видит SLOS, и R2 видит и LRDI и P-RDI, поскольку R1 является и Терминирующее оборудование канала (LTE) и Path Terminating Equipment (PTE). Так как LRDI явно не разрешает любому результирующему действию быть взятым на получение, R2 не отбрасывает интерфейс в результате. Эта проблема может потенциально привести к ситуации, где интерфейс R1 не работает, но интерфейс R2 все еще и передает трафик. Конечно, любая поддержка активности Уровня 2 (как High-Level Data Link Control (HDLC) предоставляет) вызывает таймаут и объявляет ссылку вниз, как правило, через 30 секунд, на основе настроенных таймеров. Однако много операторов отключают эти пакеты Keepalive Уровня 2 и не могут предотвратить эту ситуацию. Для рассмотрения этой проблемы можно проявить несколько подходов, и каждый подход обращается к этому от другой точки зрения, как объяснено здесь:

  • Включите Спусковые механизмы Пути — Поскольку P-RDI переводит интерфейс в нерабочее состояние с включенными спусковыми механизмами Пути, можно использовать этот метод, чтобы вызвать быстрый отклик и отбросить интерфейс. Интересный момент для замечания - то, что LRDI каширует P-RDI под нормальной работой согласно GR-253. Поскольку спусковые механизмы POS обрабатываются в количестве дефектов, спусковые механизмы обработаны перед сигнальной маскировкой, и интерфейс все еще понижается согласно настроенному времени задержки.

  • Включите Пакеты Keepalive Уровня 2 — Эта опция заставляет интерфейс на R2 испытывать таймаут после того, как пропущены 3 пакетов Keepalive. Это, как правило, - общее количество 30 секунд (3x10), и Cisco обычно не рекомендует этой опции как программное средство настроить конвергенцию быстрого канала.

  • Включите Протокол маршрутизации на основе состояния соединений — Когда интерфейс на R1 переведен в нерабочее состояние из-за SLOS, сообщение состояния канала сразу передано. Даже при том, что интерфейс на R2 может все еще возрасти, когда сообщение состояния канала получено всюду по области, SPF выполнен, и ссылка удалена из топологии, потому что ссылка отказывает двухстороннюю проверку подключения. Это препятствует тому, чтобы сеть пыталась направить через тот симплекс сценарий.

Удаленное уведомление на основе качества сигнала

При соединении двух маршрутизаторов, или встречно-параллельных, или по сети SONET, предоставленная архитектура OAM покрывает обнаружение большинства сценариев отказов.

Как правило, существуют локальные уведомления и удаленные уведомления. Однако, когда большое число Ошибок BIP пересекает порог (SD или SF или B3-TCA), никакое удаленное уведомление не передается, чтобы указать, что произошло это условие. Таким образом, когда вы используете Многопротокольную коммутацию по меткам (MPLS), Быстро Перенаправляют защиту, никакой спусковой механизм не активирует непосредственный защитный коммутатор. Трафик продолжает помещаться в черный список, пока достаточный трафик не потерян для порождения сбоя или пакетов Keepalive Уровня 2 на ссылке или отношений соседей среди узлов Протокола IGP. Иногда это никогда не происходит и продолжает помещать трафик в черный список.

Для адресации к этому сценарию CSCec85117 представляет команду pos action b3-ber prdi структуре команды SONET и POS.

Когда порог B3 был скрещен, эта команда позволяет оператору настраивать интерфейс для передачи P-RDI. Эта опция позволяет вам контролировать ссылку от начала до конца оптимально, независимо от топологии. Если путь триггеров задержки POS включен на маршрутизаторах, команда pos action b3-ber prdi активирует ссылку, которая снижается (и передача Fast ReRoute (FRR) или обновление маршрута). Это избегает эффекта черной дыры на ухудшенные ссылки.

Для изменения чувствительности этого действия настройте b3-tca как показано здесь:

router(config-if)# pos threshold b3-tca ?

Предоставленное значение является экспоненциальным компонентом для вычисления значений BER (например, "порог" "POS" "b3-tca 3" заставляет B3-TCA быть эквивалентным скорости 1x10^-3).

Связанные обсуждения сообщества поддержки Cisco

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


Дополнительные сведения


Document ID: 62622