Настройка ERPS на коммутаторах SNR

В настоящее время для большинства сетевых инженеров, IT-отделов и телеком-компаний не стоит вопрос организовывать резервирование на сети или нет. Скорее стоит вопрос как именно реализовывать это самое резервирование, чтобы уменьшить время простоя. Требования непрерывности бизнес-процессов постоянно повышаются и то, что раньше было допустимо, в настоящее время может служить поводом для написания объяснительной. Сейчас мало кто может себе позволить иметь согласованный план резервирования, заключающийся в переключении патчкорда из одного коммутатора/маршрутизатора в другой в случае наличия проблем с каналом. В данной статье предлагается к рассмотрению протокол L2-резервирования ERPS и его сравнение с семейством протоколов, наиболее распространенных на втором уровне модели OSI — семейством STP.

Описание протокола ERPS

ERPS (Ethernet Ring Protection Switching) — протокол, позволяющий осуществлять резервирование канала на втором уровне модели OSI путем физического создания петель и их логической блокировки. В каждом кольце выбирается R-APS VLAN, в котором будет ходить служебный трафик ERPS. Трафиковые VLAN’ы, которые нужно защищать от петель и разрывов, объединяются в MST-инстансы и называются protected VLAN. Также для каждого порта в кольце выбирается 1 из 3 возможных ролей: RPL owner, RPL neighbour или common. RPL owner должен быть 1 на кольцо и именно он при нормальных условиях должен выполнять блокировку петли и разблокировку канала в случае разрыва. RPL neighbour должен находиться с другой стороны линка от RPL owner и в текущей редакции стандарта G.8032/Y.1344 также может участвовать в блокировки/разблокировки канала. Common-порт, как можно судить по его названию, просто обычный порт, входящий в состав кольца и через который ходит служебный трафик в R-APS VLAN’е. Согласно стандарту G.8032/Y.1344 время сходимости должно составлять не более 50 мс при наличии в кольце не более 16 узлов. Также в настоящий момент в ERPS существует возможность выбора, будет кольцо revertive или non-revertive. В первом случае при восстановлении канала порт RPL-owner снова станет заблокированным и сбойный линк — рабочий, т.е. кольцо, вернется в исходное состояние. В случае если кольцо non-revertive, то возвращения в исходное состояние не произойдет.

Возникает резонный вопрос — ведь есть же уже семейство протоколов STP, которые решают аналогичную задачу резервирования. Зачем отходить от него? Ответ будет крыться во времени сходимости: для STP — это порядка 50 секунд, для RSTP — около 1-2 секунд, а для ERPS — 50 мс. Согласитесь, весомое преимущество. Но теперь уже возникает встречный вопрос — если же ERPS так хорош, почему не используется повсеместно? Во-первых, для его применения нужна специальная топология — кольцевая. В случае с STP его можно применить к любой топологии с любым количеством резервируемых линков, но все же помня про ограничение по количеству узлов. С ERPS номер с любой топологией не пройдет, нужны именно кольца или полукольца, о которых мы поговорим чуть позже. Во-вторых, у ERPS отличается механизм падения линка, который тоже описан ниже.

Основные алгоритмы работы ERPS

Штатная работа

Когда разрывов в кольце нет, то по нему ходят сигнальные сообщения «No Request». В данном режиме порт RPL owner заблокирован. Значение «Node State» в состоянии «IDLE».

Разрыв линка между RPL common’ами

В данном случае коммутаторы, которые обнаружили падение линка, после истечения «Hold Off Timer» посылают пакеты «Signal Failing». Коммутаторы, получившие пакет «Signal Failing», выполняют очистку таблицы MAC-адресов. Когда коммутаторы, на которых находятся RPL owner и RPL neighbour получают пакет «Signal Failing», они разблокируют указанные порты и также выполняют очистку таблицы MAC-адресов. Затем коммутаторы получают второй «Signal Failing»(от второго коммутатора, который зафиксировал падение линка) и снова выполняют очистку таблицы MAC-адресов. Назчение «Node State» в состоянии «PROTECTION».

Восстановление линка между RPL common’ами

Как только коммутаторы обнаруживают восстановление линка, они запускают «Guard Timer» и начинают посылать пакеты «No Request». Коммутаторы, получившие пакет «No Request», выполняют очистку таблицы MAC-адресов. Коммутатор, на котором находится RPL owner, запускает таймер «WTR Timer». После того, как истечет таймер «Guard Timer» один из двух коммутаторов, который зафиксировал восстановление линка, получит сообщение No Request c Node ID больше, чем свои, и разблокирует порт, который восстановился. В данном моменте времени состояние кольца будет «PENDING». Если значение «revertive mode» установлено в «revertive», то после истечения таймера «WTR Timer» коммутатор, один из портов которого RPL owner, посылает пакет «No request, RPL blocked» и блокирует порт RPL owner. После чего второй из коммутаторов, который обнаружил восстановление линка, разблокирует свой порт и кольцо вернется в исходное состояние «IDLE».

Разрыв линка между RPL owner и RPL neighbour

В случае разрыва линка между портами RPL owner и RPL neighbour коммутаторы начинают рассылать пакет «Signal Failing, Do not Flush», при получении которого остальные коммутаторы не будут сбрасывать таблицу МАС-адресов. Состояние кольца в данном случае будет «PROTECTION».

Восстановление линка между RPL owner и RPL neighbour

Алгоритм восстановления в данном случае напоминает ситуацию восстановления канала между RPL common’ами, за тем исключением, что в данном случае выставляется флаг «Do Not Flush» и коммутаторы не сбрасывают таблицу МАС-адресов.

Более подробно алгоритмы работы изложены в приложении III стандарта G.8032/Y.1344.

Особенности ERPS

Virtual channel

При настройке колец по умолчанию выставляется работа с virtual channel и идентификатор кольца Ring-ID 1. Поэтому, если при настройке колец не изменять данные параметры и задать одинаковый control vlan, то кольцо с полукольцом соберется, но разрыв 1 линка в любом из колец приведет к созданию петли. Для избежания этого можно либо задавать разные Ring-ID, либо разные control vlan, либо работать в режиме без virtual channel. Стоит отметить, что наличие/отсутствие virtual channel можно настроить только на полукольце. Нужно понимать, что virtual channel — это канал, который относится к major-ring’у, но позволяет передать через себя сигнальные сообщения sub-ring’a. В данном примере если упадет линк между WEST и EAST и линк между WEST и NORTH, то линк между WEST и SOUTH не разблокируется. Это происходит потому, что сигнальные сообщения «Signal Failing» относятся к major-ring’у, поэтому sub-ring никак реагировать не будет.

Детектирование падения линка

Обнаружить падение линка можно в двух случаях. Первый и наиболее распространенный — это падение физического интерфейса. Для того чтобы падение отрабатывалось штатно, нельзя ставить в кольце два идущих подряд коммутатора, на которых не настроен ERPS.

Второй, и наиболее эксклюзивный способ — это настройка механизма CFM(connectivity fault management). Этот протокол позволяет настроить мониторинг от «точки до точки» на уровне L2 с помощью CCM-пакетов, которые отправляются с заданной периодичностью. Таким образом, появляется таймер, в течение которого отсутствие прихода CCM-пакета позволяет сделать вывод о разрыве канала и включить режим защиты в протоколе ERPS.

Одной из интересных особенностей ERPS является тот факт, что, несмотря на постоянное присутствие в канале пакетов NR(no request), при их не получении портом RPL owner, этот порт не будет предпринимать никаких действий по включению защитного механизма ERPS.

Настройка ERPS на коммутаторах SNR

Настройка 1 кольца

Для начала предлагается рассмотреть настройку простого случая — 1 кольца из 3 коммутаторов(WEST, EAST и NORTH). В качестве тестовых коммутаторов выступают следующие модели:

1. коммутатор WEST — SNR-S2990G-24FX
2. коммутатор EAST — SNR-S2940-8G-v2
3. коммутатор NORTH — SNR-S2990G-48T
4. коммутатор SOUTH — SNR-S2960-24G

Настройка коммутатора NORTH:

Настройка коммутатора NORTH производится аналогично WEST, кроме роли порта port0. Поскольку с другой стороны линка будет RPL owner, то port0 должен быть neighbour.

#указываем, что port0 будет выполнять функцию "RPL neighbour"
WEST(config-erps-ring-inst-1)#rpl port0 neighbour  

В схеме мы видим, что port0 коммутатора WEST смотрит на port0 NORTH. Это вполне нормально, поскольку мы сами определяем значения port0 и port1. Port0 может смотреть как на port0, так и на port1. С port1 аналогично. Главное, чтобы соблюдалось правило: owner смотрит на neighbour, а common на common.

Настройка коммутатора EAST:

Настройка коммутатора EAST осуществляется аналогично WEST и NORTH, за исключением того, что на EAST роли портов port0 и port1 не указываются, будут ли они RPL owner или neighbour, т.е. они становятся по умолчанию RPL common.

В схеме и в приложенном конфиг-файле номера портов, участвующих в создании ERPS-кольца отличаются, т.к. используются разные модели коммутаторов.

Настройка коммутатора NORTH:

Настройка коммутатора NORTH производится аналогично WEST, кроме роли порта port0. Поскольку с другой стороны линка будет RPL owner, то port0 должен быть neighbour.

#указываем, что port0 будет выполнять функцию "RPL neighbour"
WEST(config-erps-ring-inst-1)#rpl port0 neighbour  

В схеме мы видим, что port0 коммутатора WEST смотрит на port0 NORTH. Это вполне нормально, поскольку мы сами определяем значения port0 и port1. Port0 может смотреть как на port0, так и на port1. С port1 аналогично. Главное, чтобы соблюдалось правило: owner смотрит на neighbour, а common на common.

Настройка коммутатора EAST:

Настройка коммутатора EAST осуществляется аналогично WEST и NORTH, за исключением того, что на EAST роли портов port0 и port1 не указываются, будут ли они RPL owner или neighbour, т.е. они становятся по умолчанию RPL common.

В схеме и в приложенном конфиг-файле номера портов, участвующих в создании ERPS-кольца отличаются, т.к. используются разные модели коммутаторов.

Убеждаемся, что Signal-Status имеет значение Non-failed на всех портах и Node State в состоянии IDLE. Это говорит о том, что кольцо создалось и работает в штатном режиме.

Также можно вывести информацию о параметрах с помощью команды show erps instans

WEST#show erps instance
ERPS Ring: test_ring1
Instance: 1
Description: -
Protected Instance: 1
Revertive mode: revertive
R-APS MEL: 7
R-APS Virtual-Channel: with
Control Vlan: 2
Ring ID: 1
Guard Timer(10ms): 50
Holdoff Timer(seconds): 0
WTR Timer(min): 5
-------------------------------------------
Port      Role             Port-Status
-------------------------------------------
Port0     RPL owner        blocked
Port1     common           forwarding

Предлагается немного остановиться на параметрах, которые ранее не рассматривались.

Revertive mode — режим работы, при котором после устранения разрыва(состояние PENDING) кольцо переходит в исходное состояние (состояние IDLE) — разблокируются все порты, кроме RPL owner и neighbour. Non-Revertive mode — режим работы, при котором после устранения разрыва блокированным остается тот линк, на котором был разрыв. Состояние кольца в этом случае будет PENDING.

R-APS MEL — уровень R-APS сообщений. Если на порт приходит сообщение, у которого R-APS MEL меньше, чем задано в ERPS-инстансе, то сообщение дальше отправляться не будет.

R-APS virtual channel — наличие виртуального канала в кольце(major-ring), по которому будут ходить сигнальные сообщения полукольца(sub-ring’a).

Ring-ID — идентификатор ERPS-кольца, являющийся последним октетом MAC-адреса назначения служебных сообщений(PDU). По умолчанию Ring-ID равен 1 и МАС-адрес в данном случае будет 01:19:a7:00:00:01.

Guard Timer — таймер, до истечения которого не будут обрабатываться сигнальные сообщения.

Holdoff Timer — таймер, до истечения которого будет игнорироваться неработоспособность линка, давая возможность линку восстановиться без срабатывания ERPS.

WTR (wait-to-restore) Timer — таймер, до истечения которого при восстановлении линка не будет переключение к исходной схеме блокировки портов в случае работы в revertive mode.

Настройка 1 кольца с полукольцом

На следующем этапе предлагается немного усложнить схему, оставив уже настроенное кольцо и подключить к коммутаторам WEST и EAST еще и SOUTH. Таким образом, к существующему кольцу(major-ring) мы подключаем полукольцо(sub-ring). Полукольцо получается из-за того, что линк между WEST и EAST уже принадлежит кольцу WEST-EAST-NORTH и мы не можем на этих же портах коммутаторов WEST и EAST прописать, что они относятся также к кольцу WEST-EAST-SOUTH.

Настройка коммутатора EAST:

Настройка коммутатора EAST осуществляется аналогично WEST, за исключением того, что rpl port0 не указывается, т.е. port0 будет RPL common, а port1 существовать не будет.

Настройка коммутатора SOUTH:

настройка коммутатора SOUTH аналогична настройке коммутатора NORTH за исключением того, что будет создано кольцо erps_ring2 с параметром  open-ring, в котором будет control vlan 4.

Конфигурационные файлы для настройки 1 кольца с полукольцом.

Результаты тестов на коммутаторах SNR

Схема представляет собой кольцо из пяти коммутаторов. Тестируемые ПК находятся на соседних коммутаторах. В нормальном режиме трафик идет по большому кольцу. Во время теста физически разрывается линк на коммутаторе с тестовым ПК, после чего трафик идет всего через 2 коммутатора. На коммутаторах SNR для ускорения времени сходимости следует ввести команду «port-scan mode interrupt». Тест представляет собой запуск пинга каждые 0,01 секунды с одного ПК до второго. Таймеры для ERPS: Hold-off timer — 0s, Guard timer — 10ms. Таймеры для RSTP: Hello timer — 2s, со стороны обоих ПК порты включены в режим portsfast. Ниже таблица со временем сходимости для каждого теста и среднее за 10 тестов. «Реверс» — время сходимости при восстановлении разорванного линка.

Таблица 1. Время сходимости ERPS и RSTP

Что удивило, при восстановлении канала быстрей оказался RSTP. Правда, разница составила всего 2 сотые секунды. Зато при пропадании линка, как и ожидалось, ERPS переключался быстрее, чем RSTP. Причем разница составляет почти целую секунду.

Заключение

Тестовое кольцо ERPS настроено, резервирование отработано, время переключения проверено. Думаю, что пора подвести итог — вспомнить преимущества и недостатки этого протокола. И начнем, пожалуй, с последних.

К «минусам» можно сразу отнести отсутствие в самом протоколе мониторинга пропадания линка на логическом уровне. Таймер с функциональностью «keep alive» отсутствует даже как вспомогательный механизм. Небольшими недостатками являются относительная сложной настройки и его применимость к уже существующей сети, поскольку требуется именно кольцевая топология, которую не всегда возможно будет реализовать за приемлемые средства.

Нейтральной особенностью является наличие 1 резервного линка на кольцо, что, с одной стороны повышает утилизацию сети при наличии резервирования, а с другой — приводит к отсутствию связности при 2 разрывах и более в 1 кольце.

Главной положительной особенностью является время сходимости. Только ради этого уже можно всерьез задумываться о внедрении этого протокола на сети. Приятным дополнением к этому станет наличие таймера «hold-off», который исключит полную неработоспособность сети в случае частого изменения состояния порта, чего нельзя сказать про семейство STP. Также еще следует отметить низкую нагрузку на CPU по сравнению с STP, ведь в ERPS логика довольно проста: есть аварийное сообщение — разблокировать порт, нет — заблокировать.