13.1 Ethernet Ring Protection (ERP)

13. High Availability and Network Optimization

13.1  Ethernet Ring Protection (ERP)

 В данной главе рассмотрен обзор протокола Ethernet Ring Protection (ERP), его настройка и проверка.

Протокол ERP

Протокол описан в ITU-T G.8032. Обеспечивает высокую надёжность, стабильность, защиту от петель в кольцевых Ethernet-топологиях, обеспечивая время сходимости менее 50 ms. Таким образом может служить заменой для STP. При применении ERP в сетях на основе «меди», рекомендуется в дополнение задействовать connectivity fault management (CFM) для помощи в обнаружении неисправностей между устройствами.Для защиты кольца Ethernet от петель, один из линков линк между двумя устройствами выступает в качестве ring protection link (RPL):13-1-1Одно из устройств (RPL Owner), к которому подключен RPL, контролирует его состояние, помещая RPL в заблокированное состояние (idle state). Это же устройство рассылает периодические сообщения Ring Automatic Protection Switching (R-APS) для информирования других устройств о состоянии RPL. Остальные устройства не выполняют никакие задачи и просто «слушают» и пересылают R-APS.

Когда происходит неисправность в каком-либо месте кольца Ethernet, то устройство, к которому подключен вышедший из строя линк, начинает рассылать сообщения R-APS, информируя другие устройства о неисправности. Контролирующее же состояние RPL устройство помещает его в состояние пересылки до тех пор, пока не устранят неисправность. Когда неисправность устранится, JunOS поместит RPL в заблокированное состояние.

Для взаимодействия друг с другом в ERP, каждое устройство участвует в APS. Каждый из двух портов каждого устройства настраивается в выделенный канал — VLAN или bridge domain — для общения по протоколу ASP. Хотя ASP-протокол использует единую VLAN для взаимодействий, изменения состояния «Forwarding» интерфейса, которое происходит при обмене R-APS-сообщениями, затрагивают все VLAN’ы порта.

R-APS-сообщения используют такой же формат фрейма, как и CFM. Исключением является Destination MAC-адрес (01-19-A7-00-00-01) и opcode = 40 у R-APS-сообщения:13-1-2

  • Request/State (4 bits): 0000 — в кольце дефектов не обнаружено (No request); 1011 — обнаружена неисправность на интерфейсе (Signal Fail state)
  • Reserved 1 (4 bits): зарезервировано, всегда 0000
  • RPL Blocked (1 bit): 1 — RPL заблокировано; 2 — RPL разблокировано. Только RPL-owner может оповещать от блокировании RPL
  • Status Reserved (6 bits): зарезервировано, всегда 000000
  • Node ID (6 octets): MAC-адрес устройства в Ethernet-кольце
  • Reserved 2 (24 octets): зарезервировано, всегда все «0»

А теперь рассмотрим как это всё работает.

1). Idle State

При отсутствии неполадок в Ethernet-ring сети все устройства находятся в состоянии «Idle State», RPL находится в заблокированном состоянии. RPL-owner отправляет каждые 5 секунд R-APS-сообщения, которые оповещают об отсутствии неисправностей в кольце (Request/State = no request), о необходимости очистить на устройствах MAC-таблицы (Do not flush = 0) и о том, что RPL находится в заблокированном состоянии (RPL Blocked = 1).13-1-3Все устройства, кроме RPL-owner’а отправившего первое R-APS-сообщение, очищают свои MAC-таблицы и переводят все интерфейсы в Ethernet-кольце в разблокированное состояние.

2). Signal Failure

Происходит, когда устройство обнаруживает повреждение на порту в кольце.13-1-4Устройства B и C обнаруживают неисправность на канале между собой. Т.к. hold interval в JunOS в данном случае не поддерживается, то B и C мгновенно реагируют на неисправность и переключаются с iddle state в protection state, блокируют порты на которых произошла неисправность, очищают свои MAC-таблицы и отправляют R-APS-сообщения для оповещения других устройств о неисправности. Это R-APS-сообщение оповещает другие устройства сети о неисправности в сети (Request/State = signal fail) и что необходимо очистить MAC-таблицы (Do not flush= 0). Сообщения отправляются каждые 5 секунд. Все устройства, кроме B и C, при получении R-APS-сообщения о неисправности, переключаются в protection state, очищают свои MAC-таблицы и перестают отправлять R-APS-сообщения.  RPL-owner снимает блокировку с RPL и продолжает «прослушивать» R-APS-сообщения.

3). Восстановление неисправного линка

Когда канал между B и C восстановлен, они начинают отправлять новые R-APS-сообщения, оповещая другие устройства о том, что неисправность устранена (Request/State = no request) и о том, что устройства не должны очищать свои MAC-таблицы (Do not flush = 1). B и C всё-ещё продолжают удерживать свои ранее заблокированные порты в заблокированном состоянии (чтобы не образовалась петля) до тех пор, пока не получат R-APS-сообщение от RPL-owner’а:13-1-5

Как только RPL-owner (устройство A) получает сообщение от B и C о восстановлении канала (Request/State = no request), устройство A включает таймер восстановления — 5 минут по-умолчанию (настраивается от 5 до 12 мин с шагом 1 мин). По прошествии этого таймера RPL-owner блокирует RPL и пересылает R-APS-сообщение, которое оповещает другие устройства об отсутствии неисправностей в сети (Request/State = no request) и о том, что устройства должны очистить MAC-таблицы (Do not flush = 0). При получении этого сообщения, все устройства очищают MAC-таблицы, разблокируют все ранее заблокированные порты в кольце. Все устройства переходят из protection state в  idle state

13-1-6

Настройка ERP.

На слайде показана настройка RPL-owner’а13-1-7Сначала настраиваются два интерфейса, которые находятся в кольце Ethernet для APS-канала (VLAN или bridge domain). В данном случае VLAN 100 используется как канал для соединения устройств.

Сам ERP настраивается в «секции» конфигурации [edit protocols protection-group]:

  • ethernet-ring pg100 — экземпляр кольца
  • ring-protection-link-owner — указывает на RPL-owner’а
  • east-interface и west-interface — задание ранее настроенных интерфейсов в качестве east- и west-интерфейсов (разницы кто будет east-, а кто west- нет, пока не применена следующая команда). Один из 2-ух интерфейсов должен быть подключен к RPL и обозначается он в конфигурации командой ring-protection-link-end
  • для интерфейсов в режиме trunk необходимо определить VLAN

Далее на слайде показана настройка обычного устройства в ERP13-1-8Всё отличие от RPL-owner’а — отсутствие команд: ring-protection-link-owner и ring-protection-link-end.

Важно запомнить, что east-interface одного устройства должен смотреть на west-interface другого, или наоборот.

Для проверки ERP используется команда show protection-group ethernet-ring с различными параметрами. Допустим из следующих выводов 2-ух команд можно сделать вывод, что команды выполнены на RPL-owner’е, т.к. R-APS-сообщение сгенерировано локальным устройством и в нём статус RPL — заблокировано:13-1-9Следующий слайд показывает информацию об интерфейсах локального устройства в ERP;  Admin State указывает, что этот интерфейс — IFF ready, т.е. Ethernet flow forwarding function (control channel) способен пересылать R-APS traffic13-1-10Детальная информация о локальном устройстве:13-1-11Просмотр статистики по ERP:13-1-12

К оглавлению

Добавить комментарий