Кат
Вы можете найти в нашем блоге подробную информацию об алгоритме работы протокола PRP. Теперь мы предлагаем «препарировать» трафик из сети с PRP. Посмотреть на RCT-трейлер, Supervision Frame и на то, как за счет всего этого организуется управление резервированием. Всем заинтересованным под кат.
PRP. Общие принципы
Все общие принцип были изложены в этой статье. Текущий пост — ее продолжение. Рекомендуем предварительно ознакомиться с первой статьей. В ее составе разобраны следующие вопросы:
Если очень кратко, то резервирование на основании PRP осуществляется за счет дублирования фреймов. Каждый фрейм дублируется отправителем, и фреймы передаются через две изолированные друг от друга сети. Принимающий узел обрабатывает фрейм, пришедший первым, и отбрасывает второй. Если фрейм приходит «битый» или одна из сетей была потеряна, то всегда есть второй фрейм. За счет этого достигается «бесшовное» резервирование – т.е. резервирование с временем схождения, практически равным 0 мс.
Общая структура сети выглядит следующим образом:
Для подробностей о том, что это за аббревиатуры, деталях работы алгоритма протокола и прочем – милости просим в статью, упоминаемую выше. В этом посте уделим больше внимания фрейму и RCT-трейлеру.
RCT расшифровывается как Redundancy Control Trailer – трейлер контроля резервирования.
Этот трейлер добавляется к фрейму. Он используется для управления резервированием.
RCT включает в себя:
Соответственно, в чем заключается управление?
Давайте «поймаем» трафик в сети с PRP и посмотрим, как работает PRP.
Перебираемся к практике
Чтобы «препарировать» фрейм с PRP, сначала нужно выполнить две задачи: сгенерировать фреймы и поймать фреймы.
«Сгенерировать»
Начнем с задачи «сгенерировать».
Соберем простенькую сеть, в которой можно найти немного PRP-пакетов.
Преследуя цель отловить все фреймы в сети с PRP, возьмем пару ноутбуков, два RedBox’а и два управляемых коммутатора.
В качестве RedBox’ов мы взяли FL RED 2003E PRP – 2701863.
В качестве коммутаторов мы взяли два FL SWITCH 2206-2FX – 2702330. Коммутаторы не энергетические и поддержка PRP в них не заявлена. Заодно проверим, как коммутаторы справляются с фреймами, содержащими RCT.
Простейшую сеть мы собрали, PRP-фреймы сгенерировали. Теперь перейдем ко второй задаче – «поймать».
«Поймать»
Чтобы поймать траффик с RCT-трейлером, мы подключим ноутбук с Wireshark на борту к одному из управляемых коммутаторов. На коммутаторе настроим Port Mirroring для зеркалирования траффика из сети на ноутбук для анализа.
Запустим пинг с одного хоста (192.168.0.200) на второй (192.168.0.60) и отловим ICMP-пакеты в Wireshark.
Что в фрейме?
Возьмем ICMP-пакет от 192.168.0.200 к 192.168.0.60.
Из скриншота в Wireshark видно, что RCT содержит на два поля больше, чем было описано в начале. Здесь еще есть версия протокола и PRP-суффикс. Ранее я опускал эти данные, т.к. они не несут полезной нагрузки.
Соответственно, в фрейме мы видим:
Что значит версия протокола?
Протокол PRP может быть двух версий:
Самый главный момент — PRP-0 и PRP-1 несовместимы.
В PRP-1 было введено несколько принципиально важных изменений:
RCT в PRP-1 стал ближе к HSR.
PRP-0 редко встречается в реальных применениях.
Что еще есть в PRP-сети?
Также каждый узел PRP отправляет Supervision Frame.
Supervision Frame используется для мониторинга статуса каждого узла в сети. Любой DAN по умолчанию каждые 2 секунды посылает Supervision Frame. Интервал посылки может быть изменен.
Supervision Frame имеет следующие параметры:
Фрейм содержит следующую информацию:
RedBox отправляет Supervision Frame «от лица» узлов, которые подключены через него к PRP-сети. В данном случае в качестве MAC в Supervision Frame указывается MAC VDAN’а и MAC самого RedBox’а. В качестве SrcMAC указывается адрес RedBox’а. RedBox посылает отдельный Supervision Frame от имени каждого узла, который за ним находится.
На данном скриншоте как раз открыт фрейм с RedBox’а. В полях PRP в качестве Source MAC Address указан узел, который находится «за RedBox’ом» и здесь же есть отдельное поле RedBox MAC Address. Но в поле Ethernet II в качестве Source MAC указан MAC-адрес RedBox’а.
Supervision фреймы также имеют RCT, как и другие пакеты в PRP-сети.
Как осуществляется управление резервированием?
Определение неправильно подключенного интерфейса
DAN или RedBox проверяют LAN ID принимаемого фрейма. Если LAN ID фрейма и интерфейса не совпадают, то устройство увеличивает счетчик ошибок LAN ID на один.
Поменяем в собранной сети на одном из RedBox’ов LAN A и LAN B местами. Попробуем получить по SNMP значение счетчика ошибок на этих интерфейсах.
На обоих интерфейсах видим практически равное количество ошибок. Значения различаются, т.к. интерфейсы были подключены не одновременно, а с небольшой разницей по времени.
Отбрасывание дублированного фрейма
RCT содержит поле sequence, в котором содержится номер последовательности фрейма. На основе этого номера реализован алгоритм отбрасывания фрейма – Duplicate Discard.
Алгоритм Duplicate Discard был подробно разобран в первое статье про PRP.
Создание NodeTables
На основе Supervision фреймов PRP-узел создает таблицу узлов – NodeTable.
В NodeTable на каждый узел (на каждую запись) содержится следующая информация:
NodeTable опциональна. Она может хранится на одном из узлов PRP и этого будет достаточно.
Заключение
PRP использует RCT-трейлер и Supervision Frame для диагностики сети. Это позволяет реализовывать алгоритм отбрасывания дублированного фрейма, определять ошибки подключения, вести учет всех PRP-узлов. Соответственно, если коммутатор считывает неверно RCT и считает, что это полет 802.1q, то он может либо потерять пакет (что очень плохо), либо удалить это поле на Untagged (access) порту (что просто плохо).
Во втором случае мы получим уже не Duplicate Discard, а Duplicate Accept. На каждый DAN будут приходить два пакета без RCT. Соответсвенно, LRE будет отправлять на верхний уровень оба пакета, рассчитывая, что TCP справится с этим. Соответственно ни о какой диагностики в этом случае речи не идет.
Вы можете найти в нашем блоге подробную информацию об алгоритме работы протокола PRP. Теперь мы предлагаем «препарировать» трафик из сети с PRP. Посмотреть на RCT-трейлер, Supervision Frame и на то, как за счет всего этого организуется управление резервированием. Всем заинтересованным под кат.
PRP. Общие принципы
Все общие принцип были изложены в этой статье. Текущий пост — ее продолжение. Рекомендуем предварительно ознакомиться с первой статьей. В ее составе разобраны следующие вопросы:
- Структура сети PRP
- Элементы сети PRP и их назначение
- Структура DAN
- Взаимодействие между SAN и DAN
- Режимы работы DAN
- Duplicate accept
- Duplicate discard
- Реализация на канальном уровне
- Алгоритм работы
Если очень кратко, то резервирование на основании PRP осуществляется за счет дублирования фреймов. Каждый фрейм дублируется отправителем, и фреймы передаются через две изолированные друг от друга сети. Принимающий узел обрабатывает фрейм, пришедший первым, и отбрасывает второй. Если фрейм приходит «битый» или одна из сетей была потеряна, то всегда есть второй фрейм. За счет этого достигается «бесшовное» резервирование – т.е. резервирование с временем схождения, практически равным 0 мс.
Общая структура сети выглядит следующим образом:
Для подробностей о том, что это за аббревиатуры, деталях работы алгоритма протокола и прочем – милости просим в статью, упоминаемую выше. В этом посте уделим больше внимания фрейму и RCT-трейлеру.
RCT расшифровывается как Redundancy Control Trailer – трейлер контроля резервирования.
Этот трейлер добавляется к фрейму. Он используется для управления резервированием.
RCT включает в себя:
- 16-битный номер последовательности;
- 4-битный идентификатор сети, 1010 (0xA) для LAN A и 1011 (0xB) для LAN B;
- 12-битный размер фрейма.
Соответственно, в чем заключается управление?
- Определение неправильного подключения интерфейсов. DAN определяет, что на LAN A приходит фрейм с LAN ID B и наоборот. В этом случае DAN увеличивает счетчик ошибок перепутанных фреймов (IreCntErrWrongLan). Устройство пакеты принимать будет, но посчитает это ошибкой и будет считать количество неверных пакетов.
- Реализация работы алгоритма Duplicate Discard. У каждого пакета есть номер последовательности и, соответственно, каждое устройство знает, с каким номером придет следующий фрейм от любого узла PRP в сети. Алгоритм отбрасывания дублированного фрейма (Duplicate Discard) работает на основе этих номеров.
- Сбор подробной информации по всем узлам в PRP-сети. В памяти узла создается таблица NodeTable, в которой содержится информация обо всех DAN и SAN в сети.
Давайте «поймаем» трафик в сети с PRP и посмотрим, как работает PRP.
Перебираемся к практике
Чтобы «препарировать» фрейм с PRP, сначала нужно выполнить две задачи: сгенерировать фреймы и поймать фреймы.
«Сгенерировать»
Начнем с задачи «сгенерировать».
Соберем простенькую сеть, в которой можно найти немного PRP-пакетов.
Преследуя цель отловить все фреймы в сети с PRP, возьмем пару ноутбуков, два RedBox’а и два управляемых коммутатора.
В качестве RedBox’ов мы взяли FL RED 2003E PRP – 2701863.
В качестве коммутаторов мы взяли два FL SWITCH 2206-2FX – 2702330. Коммутаторы не энергетические и поддержка PRP в них не заявлена. Заодно проверим, как коммутаторы справляются с фреймами, содержащими RCT.
Простейшую сеть мы собрали, PRP-фреймы сгенерировали. Теперь перейдем ко второй задаче – «поймать».
«Поймать»
Чтобы поймать траффик с RCT-трейлером, мы подключим ноутбук с Wireshark на борту к одному из управляемых коммутаторов. На коммутаторе настроим Port Mirroring для зеркалирования траффика из сети на ноутбук для анализа.
Запустим пинг с одного хоста (192.168.0.200) на второй (192.168.0.60) и отловим ICMP-пакеты в Wireshark.
Что в фрейме?
Возьмем ICMP-пакет от 192.168.0.200 к 192.168.0.60.
Из скриншота в Wireshark видно, что RCT содержит на два поля больше, чем было описано в начале. Здесь еще есть версия протокола и PRP-суффикс. Ранее я опускал эти данные, т.к. они не несут полезной нагрузки.
Соответственно, в фрейме мы видим:
- Информацию о версии PRP.
- Номер последовательности – узел PRP ведет для каждого DAN свой счетчик посланных и присланных пакетов. Это требуется для однозначного определения дублированных пакетов и работы алгоритма PRP.
- LAN ID определяет принадлежность фрейма к LAN A или LAN B. Зависит от интерфейса, с которого он был отправлен.
- Размер определяется размером поля LSDU и RCT. Не учитывает весь размер фрейма, т.к. размер других полей может измениться во время передачи. Например, при добавлении VLAN ID к фрейму во время передачи, его размер поменяется.
- PRP-суффикс. Данный суффикс одинаков для всех фреймов с PRP-трейлером и имеет значение 0x88fb. Не зависит от сети (LAN A или LAN B).
Что значит версия протокола?
Протокол PRP может быть двух версий:
- PRP-0 (PRP 2010, IEC 62439-3(2010));
- PRP-1 (PRP 2012, IEC 62439-3 (2012)).
Самый главный момент — PRP-0 и PRP-1 несовместимы.
В PRP-1 было введено несколько принципиально важных изменений:
- расширен RCT;
- изменен принцип действия алгоритма Duplicate Discard;
- была введена совместимость между DANH (HSR) и DANP (PRP).
RCT в PRP-1 стал ближе к HSR.
PRP-0 редко встречается в реальных применениях.
Что еще есть в PRP-сети?
Также каждый узел PRP отправляет Supervision Frame.
Supervision Frame используется для мониторинга статуса каждого узла в сети. Любой DAN по умолчанию каждые 2 секунды посылает Supervision Frame. Интервал посылки может быть изменен.
Supervision Frame имеет следующие параметры:
- рассылается на Multicast группу 01-15-4E-00-01-XX;
- имеет Ethertype 0x88FB;
- поля записаны в формате TLV (Tag-length-value).
Фрейм содержит следующую информацию:
- версию протокола;
- тип устройства;
- MAC-адрес узла;
- инкрементально увеличивающийся номер последовательности.
RedBox отправляет Supervision Frame «от лица» узлов, которые подключены через него к PRP-сети. В данном случае в качестве MAC в Supervision Frame указывается MAC VDAN’а и MAC самого RedBox’а. В качестве SrcMAC указывается адрес RedBox’а. RedBox посылает отдельный Supervision Frame от имени каждого узла, который за ним находится.
На данном скриншоте как раз открыт фрейм с RedBox’а. В полях PRP в качестве Source MAC Address указан узел, который находится «за RedBox’ом» и здесь же есть отдельное поле RedBox MAC Address. Но в поле Ethernet II в качестве Source MAC указан MAC-адрес RedBox’а.
Supervision фреймы также имеют RCT, как и другие пакеты в PRP-сети.
Как осуществляется управление резервированием?
Определение неправильно подключенного интерфейса
DAN или RedBox проверяют LAN ID принимаемого фрейма. Если LAN ID фрейма и интерфейса не совпадают, то устройство увеличивает счетчик ошибок LAN ID на один.
Поменяем в собранной сети на одном из RedBox’ов LAN A и LAN B местами. Попробуем получить по SNMP значение счетчика ошибок на этих интерфейсах.
На обоих интерфейсах видим практически равное количество ошибок. Значения различаются, т.к. интерфейсы были подключены не одновременно, а с небольшой разницей по времени.
Отбрасывание дублированного фрейма
RCT содержит поле sequence, в котором содержится номер последовательности фрейма. На основе этого номера реализован алгоритм отбрасывания фрейма – Duplicate Discard.
Алгоритм Duplicate Discard был подробно разобран в первое статье про PRP.
Создание NodeTables
На основе Supervision фреймов PRP-узел создает таблицу узлов – NodeTable.
В NodeTable на каждый узел (на каждую запись) содержится следующая информация:
- MAC-узла.
- Время приема последнего фрейма от узла на интерфейс А и интерфейс B.
- Флаги SAN на интерфейсе A или B, т.е. информация является ли данный узел single attached node или нет.
- Счетчик фреймов от данного узла на интерфейс А и B.
- Счетчик ошибок для интерфейсов A и B.
NodeTable опциональна. Она может хранится на одном из узлов PRP и этого будет достаточно.
Заключение
PRP использует RCT-трейлер и Supervision Frame для диагностики сети. Это позволяет реализовывать алгоритм отбрасывания дублированного фрейма, определять ошибки подключения, вести учет всех PRP-узлов. Соответственно, если коммутатор считывает неверно RCT и считает, что это полет 802.1q, то он может либо потерять пакет (что очень плохо), либо удалить это поле на Untagged (access) порту (что просто плохо).
Во втором случае мы получим уже не Duplicate Discard, а Duplicate Accept. На каждый DAN будут приходить два пакета без RCT. Соответсвенно, LRE будет отправлять на верхний уровень оба пакета, рассчитывая, что TCP справится с этим. Соответственно ни о какой диагностики в этом случае речи не идет.
