Ethernet oam что это
SUMMARY В этом разделе описывается, как интерфейсы Ethernet на Juniper Networks и операционной системе Juniper Networks Junos (Junos OS IEEE) для коммутаторов поддерживают стандарт 802.1ag для эксплуатации, администрирования и управления (OAM).
9.4. Решение проблем с конфигурацией EFM OAM
Удостоверьтесь, что хотя бы один из соседей OAM находится в активном режиме;
Для корректной доставки информации об аварии убедитесь, что SNMP настроен корректно;
Соединение в режиме loopback-тестирования не работает. После проверки состояния линии необходимо отключить этот режим;
Для корректной работы loopback-тестирования убедитесь, что на портах не сконфигурированы STP, MRPP, ULPP, flow control, loopback-detection, а оба устройства поддерживают функцию loopback-тестирования.
CFM Maintenance Domain
The CFM Maintenance Domain object represents an instance of a CFM management space used to manage and administer a network. A CFM management domain is owned and operated by a single entity and defined by the set of ports internal to it and at its boundary.
Table Of Contents
CFM Maintenance Point
The CFM Maintenance Point object represents an instance of a CFM maintenance point configured on one or more of a device's interfaces.
Понимание управления сбоями подключения Ethernet OAM для коммутаторов
Спецификация IEEE 802.1ag предусматривает управление неисправностями соединений Ethernet (CFM). CFM следит за сетями Ethernet, которые могут включать один или несколько экземпляров обслуживания из-за сбоей ненадежков к сети.
Основные функции CFM:
Наблюдение за ошибками с помощью протокола проверки целостности. Это протокол обнаружения и проверки состояния соседей, который обнаруживает и поддерживает соседства на уровне VLAN.
Обнаружение пути и проверка ошибок с помощью протокола linktrace.
Разлиять ошибки с помощью протокола обратной связи.
CFM разделит сервисную сеть на различные административные домены. Например, операторы, поставщики и клиенты могут явться частью различных административных доменов. Каждый административный домен соедему в один домен обслуживания, который предоставляет достаточно информации для выполнения собственного управления, избегая таким образом нарушений безопасности и делая возможным прямой мониторинг.
Чтобы включить CFM на интерфейсе Ethernet, необходимо настроить домены обслуживания, связи обслуживания и конечные точки связи обслуживания (MEP). показывает отношения между доменами обслуживания, конечными точками связи обслуживания (MEP) и промежуточными точками обслуживания Рис. 1 (MPS), настроенными на коммутаторе.
7.1.2. Динамическое агрегирование LACP
Сравнение ID устройств (приоритет системы + MAC адресе системы). Если приоритет устройств одинаков - сравниваются MAC адреса устройств. Наименьший номер будет иметь наивысший приоритет;
Сравнение ID портов (приоритет порта + идентификатор порта). Для каждого порта на стороне устройства с наивысшим приоритетом системы сравниваются приоритеты портов. Если приоритеты одинаковые - сравниваются ID портов. Порт с наименьшим идентификатором порта становится выбранным (selected), а остальные - в режим ожидания (standby).
В данной Port-Group порт с наименьшим идентификатором и статусом standby становится мастер-портом. Другие порты со статусом selected становятся членами группы.
7.3. Пример конфигурации агрегации портов
Сценарий 1: LACP
Рисунок 11.1 - LACP
Коммутаторы Switch A и Switch B соединены между собой с помощью 4х линий: порты 1/0/1-1/0/4 коммутатора Switch A добавлены в port-group 1 в режиме active, порты 1/0/7-1/0/10 коммутатора Switch B добавлены в port-group 2 в режиме passive. В результате конфигурации и согласований LACP порты 1/0/1-1/0/4 коммутатора Switch A будут объединены в интерфейс “Port-Channel1”, а порты 1/0/7-1/0/10 коммутатора Switch B будут объединены в интерфейс “Port-Channel2”.
Конфигурация будет выглядеть следующим образом:
Сценарий 2: Ручное агрегирование портов
Рисунок 11.2 - Ручное агрегирование портов
Коммутаторы Switch A и Switch B соединены между собой с помощью 4х линий: порты 1/0/1-1/0/4 коммутатора Switch A добавлены в port-group 1 в режиме on, порты 1/0/7-1/0/10 коммутатора Switch B добавлены в port-group 2 в режиме on.
В результате выполнения конфигурации описанной выше, порты добавляются в Port-Channel сразу, как только выполняется команда , задающая режим on. Обмен LACPDU не требуется.
Ограничения CFM на коммутаторах серии QFX5120, QFX5200 и QFX5210
Начиная с Junos OS 18.4R1, Junos OS CFM поддерживается на QFX5200 и коммутаторах QFX5210. Начиная с Junos OS 19.4R1, Junos OS CFM поддерживается на коммутаторах QFX5120. Поддержка CFM на коммутаторах серии QFX5120, QFX5200 и QFX5210 имеет следующие ограничения:
Поддержка CFM предоставляется программным обеспечением с использованием фильтров. Это может повлиять на масштабирование.
Режим inline модуль передачи пакетов (PFE) не поддерживается. В режиме inline PFE можно делегировать периодическую обработку пакетов (PPM) на модуль передачи пакетов (PFE), что приводит к более быстрой обработке пакетов и поддерживаемой интервалу CCM в 10 миллисекунд.
Мониторинг производительности (ITU-T Y.1731 Ethernet Service OAM) не поддерживается.
Интервал CCM менее 1 секунды не поддерживается.
CFM не поддерживается на маршрутных интерфейсах и агрегированных интерфейсах Ethernet (lag).
Функция половины MIP, поделить функциональность MIP на два однонаправленных сегмента для повышения зоны уверенного обслуживания сети, не поддерживается.
Кому из нас не приходилось иметь дело с агрегацией каналов, настраивать LACP и медитировать на идеальную балансировку?
Всё здесь прекрасно, LAG обеспечивает резервирование – один линк падает, LACP удаляет его и работаем на оставшихся. Казалось бы. Но известная многим проблема в том, что LACP никак не отследит такую ситуацию:
Оптический порт перейдёт в состояние Down только если на его входе нет сигнала. То есть в вышеуказанном примере порт GE1/1/4 на R2 упадёт, а на R1 – нет. LACP на R2 отработает, а на R1 нет. Налицо потери трафика.
Для отслеживания таких проблем используются протоколы UDLD – UniDirectional Link Detection. К ним относятся BFD и Ethernet OAM. Оба они прекрасно справляются со своей задачей: если связь с удалённым устройством пропадает, UDLD вынуждает маршрутизатор перевести соответствующий порт в состояние Down. В случае, который я хочу рассмотреть , схема несколько более сложная:
То есть между двумя маршрутизаторами ещё сеть SDH. OSN принимает Ethernet-кадры, инкапсулирует их в SDH-фреймы и отправляет их в плавание. С другого конца другой OSN вылавливает их, декапсулирует обратно Ethernet и возвращает их назад в IP-сеть.
Инженер остановил свой выбор на Ethernet OAM для детектирования проблемы и. ошибся. Сам я прежде не сталкивался с данным протоколом, поэтому в лаборатории собрал тестовый стенд без SDH сети – всё работает. SDH не стал настраивать по той простой причине, что это транспорт – какая ему разница, что передавать? Резать и дропать он ничего не должен – что получил, то и отправил. У меня работает, у заказчика нет – начинаем углубляться в детали.
Для начала разберёмся, что такое OAM вообще и как применяется.
Существует их два вида:
EFM OAM – Ethernet in First Mile. Преследует следующие цели: обнаружение партнёра, мониторинг линка, уведомление об авариях, Remote Loopback. EFM OAM соответствует стандарту 802.3ah и ориентирован на отслеживание состояния простого линка.
Ethernet CFM – Connectivity Fault Management – 802.3ag. Это механизм масштаба сети и призван обеспечивать End-to-End связность. Это достаточно мощный протокол и теоретически может использоваться для данных целей, но это всё равно, что поднимать OSPF между своим DLink и компьютером. Можно, но зачем?
Итак, поскольку был выбран EFM OAM, то копнём его поглубже.
EFM определяется на конкретном интерфейсе и может работать в двух режимах – Active и Passive. Только Active инициирует поиск соседа путём отправки OAMPDU в линк. Passive же слушает и отвечает на пришедшие запросы, но не может инициировать поиск соседа. Таким образом, хотя бы один из двух подключенных друг к другу интерфейсов должен иметь EFM в режиме Active. Вот типичная конфигурация:
interface GigabitEthernet1/1/4
eth-trunk 22
efm enable
efm trigger if-down
Последняя команда вынуждает устройство переводить интерфейс в состояние Down при наличии проблем. А вот так выглядит обмен любезностями и успешное установление сессии:
И вот тут, глядя на вид OAMPDU, я начинаю подозревать, что наличие SDH-сети в промежутке может играть фатальную роль. В качестве адреса отправителя стоит MAC-адрес Eth-trunk интерфейса, а вот в качестве получателя, какой-то специальный MAC-адрес, и EtherType – Slow Protocol.
- Быстрые. Они должны отрабатывать моментально для предотвращения потери производительности. Как правило они реализуются аппаратно. Примером может служить механизм PAUSE – когда порт устройства получает трафика больше, чем может обработать, он отсылает PAUSE Frame противоположному узлу с просьбой понизить скорость отправки.
- Медленные – те самые Slow Protocols. У них не такие большие аппетиты на частоту отправки и задержки. Они реализуются программно. OAM и LACP относятся именно к этому виду. Для них используется специальный MAC-адрес: – 0180-с200-0002, и EtherType 8809.
Выдержка из Annex 57A к стандарту 802.3:
This address is within the range reserved by ISO/IEC 15802-3 (MAC Bridges) for link-constrained protocols. As such, frames sent to this address will not be forwarded by conformant MAC Bridges; its use is restricted to a single link
Дело в том, что EFM OAM относится к группе протоколов, скажем так, "одного линка". Их данные не могут покинуть один простой линк. Как только противоположное устройство принимает такой фрейм, оно его обрабатывает нужным образом и уничтожает, не передавая никуда дальше. То есть, когда с обратной стороны у нас стоит маршрутизатор/коммутатор с настроенным EFM на интерфейсе, он, приняв OAMPDU, проверяет его и отправляет ответ на R1, а старый кадр уничтожает. R1 получает OAMPDU от R2 и сессия установлена в лучшем виде.
[R2]dis efm ses al
Interface EFM State Loopback Timeout
----------------------------------------------------------------------
GigabitEthernet1/1/4 detect --
GigabitEthernet1/1/6 detect --
В нашем же случае OSN, получив такой фрейм, просто отбрасывает его, потому что никакого EFM на нём не запущено.
[R1]dis efm session all
Interface EFM State Loopback Timeout
----------------------------------------------------------------------
GigabitEthernet1/1/4 discovery --
GigabitEthernet1/1/6 discovery --
Для очистки совести я собрал полностью аналогичную схему и увидел, что R1, как активный член партии отсылает данные, но ничего не получает в ответ. А на R2 совсем всё тихо.
debugging efm interface GigabitEthernet 1/1/4 all
Info: Operation succeeded.
May 14 2013 09:18:26.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
May 14 2013 09:18:27.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
May 14 2013 09:18:28.880.1+03:00 R1 EFM/7/OAMPDU:Slot=1;
EFM GigabitEthernet1/1/4 Send Packet
Flags:00 08
Code:00
01 10 01 00 00 00 0F 00 80 00 E0 FC 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00
Замечу также, что LACP в таком виде тоже отрабатывать не будет – его кадры тоже не будут доходить до удалённой стороны по той же причине.
Единственный здесь выход – это использование BFD – Bidirectional Forwarding Detection. В то время, как EFM свои данные инкапсулирует напрямую в Ethernet, BFD использует IP и UDP. То есть для него никакой трудности не представляют промежуточные L2-устройства.
BFD отправляет свои пакеты на мультикастовый адрес 224.0.0.184 и, если противоположное устройство настроено соответствующим образом, оно высылает ответные пакеты – BFD-сессия поднимается. Вот пример конфигурации, которая принуждает устройство погасить интерфейс в случае проблем:
R1
bfd TEST bind peer-ip default-ip interface GigabitEthernet1/1/4
discriminator local 10
discriminator remote 11
process-interface-status
commit
R2
bfd TEST bind peer-ip default-ip interface GigabitEthernet1/1/4
discriminator local 11
discriminator remote 10
process-interface-status
commit
Первой строкой задаём привязку BFD к физическому интерфейсу. Далее определяем дискриминаторы – обязательный параметр BFD, позволяющий различать сессии. И командой process-interface-status указываем, что устройство должно гасить интерфейс, если BFD обнаружил проблему.
В случае проблемы на линке BFD это сразу замечает:
May 14 2013 09:45:45+03:00 R2 %%01BFD/4/STACHG_TODWN(l)[23]:Slot=1;BFD session changed to Down. (SlotNumber=1, Discriminator=20, Diagnostic=DetectDown, Applications=IFNET, ProcessPST=False, BindInterfaceName=GigabitEthernet1/1/6, InterfacePhysicalState=Up, InterfaceProtocolState=Down)
Статус интерфейса принимает вид:
[R2]dis int br
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(b): BFD down
(e): ETHOAM down
(d): Dampening Suppressed
InUti/OutUti: input utility/output utility
Interface PHY Protocol InUti OutUti inErrors outErrors
Aux0/0/1 down down 0% 0% 0 0
Eth-Trunk22 up up 0.05% 0.05% 0 0
GigabitEthernet1/1/4 up up 0.05% 0.05% 0 0
GigabitEthernet1/1/6 up up(b) 0% 0% 0 0
[R2]dis int gig1/1/6
GigabitEthernet1/1/6 current state : UP
Line protocol current state : UP(BFD status down)
Разумеется, BFD также детектирует обрыв одного оптического кабеля. Правда смысл LACP в такой ситуации, так или иначе, теряется. Ещё одно из преимуществ BFD (скорость реакции) - это уровень миллисекунд.
Вообще говоря, многие устройства поддерживают команды, которые позволяют "прокидывать" данные Slow Protocls, но это от лукавого. В общем решение предоставлено, инженер счастлив, а я узнал для себя что-то новое.
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
CFM Service
The CFM Service object represents an instance of CFM enabled on a device.
7.4. Решение проблем при конфигурации агрегации портов
Убедитесь , что все порты в группе имеют одинаковую конфигурацию, используются в режиме полного дуплекса и имеют одинаковую скорость.
Некоторые команды, такие как arp, bandwidth, ip и ip-forward, не могут быть использованы на портах в Port-Group.
EFM OAM (Ethernet in the First Mile Operation, Administration and Maintenance) позволяет своевременно обнаруживать неисправности в канале данных, за счет чего повышая его надежность. Для своей работы использует канальный уровень: для обмен OAMPDU используется MAC-адрес назначения 01-80-c2-00-00-02.
Мониторинг канала.
В сети Ethernet затруднено обнаружение неисправности, когда соединение не разрывается, но работоспособность сети нарушена. EFM OAM обеспечивает мониторинг канала с помощью уведомлений OAMPDU. При обнаружении неисправности в канале модуль OAM посылает уведомление удаленному устройству, записывает это событие в лог и посылает SNMP Trap системе мониторинга. При получении уведомления о проблеме, удаленное устройство он так же записывает информацию в лог и отправляет уведомление системе мониторинга. Анализируя информацию в логах, сетевой администратор может отследить состояние канала в определенный период времени.
Мониторинг канала с помощью EFM OAM отслеживает следующие события:
Errored symbol period event: количество ошибочных символов не может быть меньше нижнего порога ошибок (здесь символ — минимальный блок передачи информации в физической среде. Он уникален для системы кодировки, символы могут отличаться в разных физических средах. Скорость передачи символа определяется физической скоростью передачи в данной среде);
Errored frame event: Определяет N как период фреймов, число ошибочных фреймов за период приема N фреймов не должно быть меньше нижнего порога ошибок (ошибочный фрейм определяется по CRC).
Errored frame period event: количество определенных ошибочных фреймов за М секунд не должно быть меньше нижнего порога ошибок;
Errored frame seconds event: количество секунд приема ошибочных фреймов зафиксированных за М секунд не может быть ниже порога ошибок.
Loopback-тестирование линии
После активации режима loopback-тестирования, работающий в активном режиме OAM порт посылает запрос loopback-тестирования соседу, в этом случае он возвращает все пакеты, за исключением Ethernet OAMPDU, отправителю по тому же каналу. Периодическое выполнение тестирования помогает вовремя определить сетевые проблемы и локализовать их.
Link OAM
Link OAM allows network operators to monitor and troubleshoot a single Ethernet link. It is an optional sublayer implemented in the Data Link Layer between the Logical Link Control (LLC) and MAC sublayers of the Open Systems Interconnect (OSI) model. You can monitor a link for critical events and, if needed, put a remote device into loopback mode for link testing. Link OAM also discovers unidirectional links, which are created when one transmission direction fails.
OAM information is conveyed in Slow Protocol frames (see Annex 57A) called OAM Protocol Data Units (OAMPDUs). OAMPDUs contain the appropriate control and status information used to monitor, test and troubleshoot OAM-enabled links. OAMPDUs traverse a single link, being passed between peer OAM entities, and as such, are not forwarded by MAC clients (e.g., bridges or switches).
9.3. Пример конфигурации EFM OAM
Коммутаторы оператора (PE) и клиента (CE) подключены друг к другу линией с использованием EFM OAM. При возникновении аварийных ситуаций информация о линии передается в систему мониторинга. Также при необходимости используется loopback-тестирование.
Конфигурация коммутатора клиента (СЕ):
Конфигурация коммутатора оператора (PE):
CFM Maintenance Endpoint
The CFM Maintenance Endpoint object represents an instance of a CFM Maintenance Endpoint (MEP),. Unlike MIPs, MEPs are associated by a CFM Maintenance Association (S-VLAN).
Агрегирование портов - это процесс объединения нескольких портов с одинаковой конфигурацией и для использования их логически в качестве одного физического порта (Port-Channel), что позволяет суммировать полосу пропускания в одном логическом линке и использовать резервирование. Для агрегации портов на коммутаторах SNR используется Port-Group, который должен быть создан и добавлен на порты для работы их как часть одного Port-Channel.
Для создания и корректной работы порты-члены интерфейса Port-Channel должны работать в дуплексном режиме ( full-duplex ) и иметь одинаковую конфигурацию.
После объединения физические порты могут конфигурироваться одновременно как один логический интерфейс Port-channel. Система автоматически установит порт с наименьшим номером в качестве Master port. Если на коммутаторе включен функционал spanning tree protocol(STP),то STP будет рассматривать Port-Channel как логический порт и отправлять кадры BPDU через Master port.
Коммутатор позволяет объединять физические порты любых двух коммутаторов, существует ограничение на максимальное число групп - 14, и максимальное число портов в каждой группе - 8.
Ограничения CFM на EX4600 коммутаторах
Начиная с Junos OS 18.3R1, Junos OS cfM поддерживается только EX4600. Поддержка CFM на EX4600 имеет следующие ограничения:
Поддержка CFM предоставляется программным обеспечением с использованием фильтров. Это может повлиять на масштабирование.
Режим inline модуль передачи пакетов (PFE) не поддерживается. В режиме inline PFE можно делегировать периодическую обработку пакетов (PPM) на модуль передачи пакетов (PFE), что приводит к более быстрой обработке пакетов и поддерживаемой интервалу CCM в 10 миллисекунд.
Мониторинг производительности (ITU-T Y.1731 Ethernet Service OAM) не поддерживается.
Интервал CCM менее 1 секунды не поддерживается.
CFM не поддерживается на маршрутных интерфейсах и агрегированных интерфейсах Ethernet (lag).
Функция половины MIP, поделить функциональность MIP на два однонаправленных сегмента для повышения зоны уверенного обслуживания сети, не поддерживается.
Up MEP не поддерживается.
Общее число поддерживаемых сеансов CFM составляет 20.
Technology Description
This section provides the following Ethernet OAM technology descriptions:
•CFM
•Link OAM
•Ethernet LMI
Ethernet Connectivity Fault Management (CFM) is an end-to-end, per-service-instance Ethernet layer operations, administration, and maintenance (OAM) protocol. It includes proactive connectivity monitoring, fault verification, and fault isolation for large Ethernet MANs and WANs. "End-to-end" can mean PE-to-PE or CE-to-CE. A service can be identified as a service provider VLAN (S-VLAN) or an Ethernet Virtual Connection (EVC) service. Cisco ANA supports both
Cisco Proprietary Draft 1 (CFM D1) and Ethernet CFM IEEE 802.1ag Standard, using a a common IMO model.
7.2. Конфигурация агрегации портов
Добавить порт в Port-Group для агрегации, выбрать режим;
Войти в режим конфигурации Port-Channel;
Выбрать метод балансировки трафика;
Задать приоритет системы для LACP;
Задать приоритет порта для LACP;
Задать режим тайм-аута для LACP.
Команда
Описание
no port-group port-group-number>
! В режиме глобальной конфигурации
Создать Port-Group. Команда no удаляет Port-Group.
2. Добавить порт в Port-Group для агрегации, выбрать режим:
Команда
Описание
! В режиме конфигурации порта
3. Войти в режим конфигурации Port-Channel:
Команда
Описание
! В режиме глобальной конфигурации
Войти в режим конфигурации Port-Channel. - соответствует port-group-number> созданной Port-Group.
4. Выбрать метод балансировки трафика:
Команда
Описание
! В режиме глобальной конфигурации
Выбрать метод балансировки трафика для всех Port-Channel. Команда no возвращает метод по-умолчанию - src-mac.
5. Задать приоритет системы для LACP:
Команда
Описание
lacp system-priority system-priority>
no lacp system-priority
! В режиме глобальной конфигурации
Задать приоритет системы для LACP. Команда no возвращает приоритет по-умолчанию - 32768.
6. Задать приоритет порта для LACP:
Команда
Описание
lacp port-priority port-priority>
no lacp port-priority
! В режиме конфигурации порта
Задать приоритет порта для LACP. Команда no возвращает приоритет по-умолчанию - 32768.
7. Задать режим тайм-аута для LACP:
Команда
Описание
no lacp timeout
! В режиме конфигурации порта
Выбрать режим таймаута порта для LACP. Команда no возвращает конфигурацию по-умолчанию - long.
Ethernet OAM
This chapter describes the level of support that Cisco ANA provides for Ethernet Operations, Administration, and Management (OAM), as follows:
•Technology Description
•Information Model Objects (IMOs)
•Vendor-Specific Inventory and IMOs
•Service Alarms
Information Model Objects (IMOs)
7.1.1. Статическое агрегирование
Статическое агрегирование производится путем ручного конфигурирования пользователем и не требует использования протокола LACP. При конфигурировании статического агрегирования используется режим “on” для добавления порта в Port-Group.
Ethernet LMI
Ethernet Local Management Interface (Ethernet LMI) is a protocol that runs on the Provider Edge (PE) to Customer Edge (CE) UNI link and notifies the CE of connectivity status and configuration parameters of Ethernet services available on the CE port. Ethernet LMI interoperates with an OAM protocol, such as CFM, that runs within the provider network to collect OAM status.
Ethernet LMI provides information that enables autoconfiguration of customer edge (CE) devices and provides the status of Ethernet virtual connections (EVCs) for large Ethernet metropolitan-area networks (MANs) and WANs. Specifically, Ethernet LMI notifies a CE device of the operating state of an EVC and the time when an EVC is added or deleted. Ethernet LMI also communicates the attributes of an EVC and a user-network interface (UNI) to a CE device.
9.2. Конфигурация EFM OAM
Включить EFM OAM на порту;
Настроить мониторинг соединения;
Настроить обнаружение удаленных неисправностей;
Команда
Описание
! В режиме конфигурации порта
Включить функцию EFM OAM на порту. Команда no отключает эту функцию.
! В режиме конфигурации порта
Выбрать режим работы EFM OAM на порту: active (по-умолчанию) - коммутатор будет пытаться установить соединение на данном порту; passive - коммутатор будет ждать запроса на установление соединения.
no ethernet-oam period
! В режиме конфигурации порта
Задать интервал отправки пакетов OAMPDU. Команда no восстанавливает значение по-умолчанию - 1 секунда.
no ethernet-oam timeout
! В режиме конфигурации порта
Задать тайм-аут OAM сессии. Команда no восстанавливает значение по-умолчанию - 5 секунд.
2. Настроить мониторинг соединения:
Команда
Описание
no ethernet-oam link-monitor
! В режиме конфигурации порта
Включить отслеживание локальных ошибок в канале (по-умолчанию включено). Команда no отключает эту функцию.
no ethernet-oam errored-symbol-period
! В режиме конфигурации порта
Задать нижний порог ошибок и окно фиксации ошибочных символов. Команда no возвращает значение по-умолчанию ( - 1, window - 5).
no ethernet-oam errored-frame-period
! В режиме конфигурации порта
Задать нижний порог ошибок и окно фиксации периода ошибочных кадров. Команда no возвращает значение по-умолчанию ( - 1, window - 5).
no ethernet-oam errored-frame
! В режиме конфигурации порта
Задать нижний порог ошибок и окно фиксации ошибочных кадров. Команда no возвращает значение по-умолчанию ( - 1, window - 5).
no ethernet-oam errored-frame-seconds
! В режиме конфигурации порта
Задать нижний порог ошибок и окно фиксации секунд ошибочных кадров. Команда no возвращает значение по-умолчанию ( - 1, window - 300).
3. Настроить обнаружение удаленных неисправностей:
Команда
Описание
no ethernet-oam remote-failure
! В режиме конфигурации порта
Выключить режим отправки критических событий OAM (превышен threshold high) на порту через OAMPDU (по-умолчанию включено). Команда no отключает эту функцию.
ethernet-oam errored-symbol-period threshold high
no ethernet-oam errored-symbol-period threshold high
! В режиме конфигурации порта
Задать верхний порог ошибок приема символов за период. Команда no отключает этот порог.
ethernet-oam errored-frame-period threshold high
no ethernet-oam errored-frame-period threshold high
! В режиме конфигурации порта
Задать верхний порог ошибок приема кадров за период. Команда no отключает этот порог.
ethernet-oam errored-frame threshold high
no ethernet-oam errored-frame threshold high
! В режиме конфигурации порта
Задать верхний порог ошибок приема кадров. Команда no отключает этот порог.
ethernet-oam errored-frame-seconds threshold high
no ethernet-oam errored-frame-seconds threshold high
! В режиме конфигурации порта
Задать верхний порог секунд ошибок приема кадров. Команда no отключает этот порог.
no ethernet-oam remote-loopback
! В режиме конфигурации порта
Включить режим loopback-тестирования. Команда no отключает эту функцию
ethernet-oam remote-loopback supported
no ethernet-oam remote-loopback supported
! В режиме конфигурации порта
Включить режим поддержки удаленного loopback-тестирования. Команда no отключает эту функцию.
Читайте также: