В настоящее время для большинства сетевых инженеров, 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). В качестве тестовых коммутаторов выступают следующие модели:
- коммутатор WEST – SNR-S2990G-24FX
- коммутатор EAST – SNR-S2940-8G-v2
- коммутатор NORTH – SNR-S2990G-48T
- коммутатор SOUTH – SNR-S2960-24G
Настройка коммутатора WEST:
Настройка коммутатора 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.
Настройка коммутатора WEST:
Настройка коммутатора EAST:
Настройка коммутатора EAST осуществляется аналогично WEST, за исключением того, что rpl port0 не указывается, т.е. port0 будет RPL common, а port1 существовать не будет.
Настройка коммутатора SOUTH:
настройка коммутатора SOUTH аналогична настройке коммутатора NORTH за исключением того, что будет создано кольцо erps_ring2 с параметром open-ring, в котором будет control vlan 4.
Конфигурационные файлы для настройки 1 кольца с полукольцом.
Коммутатор EAST
Коммутатор WEST
Коммутатор NORTH
Коммутатор SOUTH
Результаты тестов на коммутаторах SNR
Схема представляет собой кольцо из пяти коммутаторов. Тестируемые ПК находятся на соседних коммутаторах. В нормальном режиме трафик идет по большому кольцу. Во время теста физически разрывается линк на коммутаторе с тестовым ПК, после чего трафик идет всего через 2 коммутатора. На коммутаторах SNR для ускорения времени сходимости следует ввести команду “port-scan mode interrupt”. Тест представляет собой запуск пинга каждые 0,01 секунды с одного ПК до второго. Таймеры для ERPS: Hold-off timer – 0s, Guard timer – 10ms. Таймеры для RSTP: Hello timer – 2s, со стороны обоих ПК порты включены в режим portsfast. Ниже таблица со временем сходимости для каждого теста и среднее за 10 тестов. “Реверс” – время сходимости при восстановлении разорванного линка.
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | среднее время, c | |
| ERPS | 0,19 | 0,02 | 0,27 | 0,05 | 0,1 | 0,14 | 0,14 | 0,13 | 0,02 | 0,16 | 0,122 |
| ERPS реверс | 0,03 | 0,05 | 0,02 | 0,03 | 0,03 | 0,03 | 0,02 | 0,05 | 0,03 | 0,03 | 0,032 |
| RSTP | 0,93 | 0,93 | 0,87 | 1 | 0,96 | 0,8 | 0,93 | 1,01 | 0,86 | 1,02 | 0,931 |
| RSTP реверс | 0,02 | 0,01 | 0,01 | 0,01 | 0,01 | 0,01 | 0,01 | 0,01 | 0,01 | 0,01 | 0,011 |
Таблица 1. Время сходимости ERPS и RSTP
Что удивило, при восстановлении канала быстрей оказался RSTP. Правда, разница составила всего 2 сотые секунды. Зато при пропадании линка, как и ожидалось, ERPS переключался быстрее, чем RSTP. Причем разница составляет почти целую секунду.
Заключение
Тестовое кольцо ERPS настроено, резервирование отработано, время переключения проверено. Думаю, что пора подвести итог – вспомнить преимущества и недостатки этого протокола. И начнем, пожалуй, с последних.
К “минусам” можно сразу отнести отсутствие в самом протоколе мониторинга пропадания линка на логическом уровне. Таймер с функциональностью “keep alive” отсутствует даже как вспомогательный механизм. Небольшими недостатками являются относительная сложной настройки и его применимость к уже существующей сети, поскольку требуется именно кольцевая топология, которую не всегда возможно будет реализовать за приемлемые средства.
Нейтральной особенностью является наличие 1 резервного линка на кольцо, что, с одной стороны повышает утилизацию сети при наличии резервирования, а с другой – приводит к отсутствию связности при 2 разрывах и более в 1 кольце.
Главной положительной особенностью является время сходимости. Только ради этого уже можно всерьез задумываться о внедрении этого протокола на сети. Приятным дополнением к этому станет наличие таймера “hold-off”, который исключит полную неработоспособность сети в случае частого изменения состояния порта, чего нельзя сказать про семейство STP. Также еще следует отметить низкую нагрузку на CPU по сравнению с STP, ведь в ERPS логика довольно проста: есть аварийное сообщение – разблокировать порт, нет – заблокировать.