Страница 1 из 1

какова логика работы промежуточных узлов erps?

Добавлено: 12 ноя 2022 21:43
d771
Здравствуйте!
В kb eltex (https://docs.eltex-co.ru/pages/viewpage ... d=45461800) по настройке erps даны команды для промежуточных коммутаторов 3 и 4:
console(config-erps)# protected vlan add 20,30,40


Эти коммутаторы не являются ни rpl owner ни rpl neighbor (ими являются коммутаторы 1 и 2), где происходит блокировка трафика, они просто промежуточные и отправляют signal fail при аварии.
Что изменится, если protected vlan на них вообще не указывать? Или это просто ошибка в инструкции?

Re: какова логика работы промежуточных узлов erps?

Добавлено: 14 ноя 2022 09:59
Евгений Т
Добрый день.

Ошибки нет. Protected vlan должны быть настроены на всех коммутаторах независимо от того являются ли они owner/neighbor или нет.
Линк ERPS блокирует логически только для protected vlan. Допустим у вас разорвалось кольцо где-то в середине (не RPL линк поднялся). Потом кольцо восстановилось и запустился на оунере RPL timer. Пока он длится, бывший разорванный линк блокируется логически. А если protected vlan не прописать, то начинается шторм.

Re: какова логика работы промежуточных узлов erps?

Добавлено: 15 ноя 2022 12:50
d771
Евгений Т писал(а):Линк ERPS блокирует логически только для protected vlan.

Это я понимаю. Но согласно описанию erps блокировка происходит только на узлах "owner" и "neighbor" в сторону друг друга.
Допустим у вас разорвалось кольцо где-то в середине (не RPL линк поднялся). Потом кольцо восстановилось и запустился на оунере RPL timer. Пока он длится, бывший разорванный линк блокируется логически. А если protected vlan не прописать, то начинается шторм.

В вашем примере опять же, блокирует owner. А я писал про транзитные узлы.
То есть вопрос: что делает прописывание protected vlan, на узлах, которые не являются ни owner ни neighbor, если трафик на них все равно не блокируется (как минимум так написано в рекомендации ITU).
Документация ITU также указывает только на одну точку блокировки трафика между neigbor и owner:
https://www.itu.int/rec/dologin_pub.asp ... type=items (страница 10)
Для теста я разрывал кольцо в этих точках и шторма не было.

Re: какова логика работы промежуточных узлов erps?

Добавлено: 15 ноя 2022 13:04
Евгений Т
В вашем примере опять же, блокирует owner. А я писал про транзитные узлы.

И я писал про транзитные узлы. Специально в примере отметил, что рвётся НЕ RPL линк.

Это я понимаю. Но согласно описанию erps блокировка происходит только на узлах "owner" и "neighbor" в сторону друг друга.

Блокировка между owner и neighbor происходит только в статусе кольца IDLE. Если рвётся и восстанавливается не RPL линк, то в статусе Pending он остаётся заблокированным (только с одной стороны)
Доказательство в приложенном вами стандарте:
The following sequence describes the steps in Figure III.2.
A. Stable SF condition.
B. Recovery of link failure.
C. Ethernet ring nodes C and D detect clearing of SF condition, start the guard timer and initiate
the periodical transmission of R-APS (NR) messages on both ring ports. (The guard timer
prevents the reception of R-APS messages.)
D. When the Ethernet ring nodes receive an R-APS (NR) message, the (node ID, BPR) pair of
a receiving ring port is deleted and the RPL owner node starts the WTR timer.
E. When the guard timer expires on Ethernet ring nodes C and D, they may accept the new
R-APS messages that they receive. Ethernet ring node D receives an R-APS (NR) message
with a higher node ID from Ethernet ring node C and unblocks its non-failed ring port.
F. On expiration of the WTR timer, the RPL owner node blocks its end of the RPL, sends an
R-APS (NR, RB) message with the (node ID, BPR) pair and performs the FDB flush.
G. When Ethernet ring node C receives an R-APS (NR, RB) message, it removes the block on
its blocked ring ports and stops sending R-APS (NR) messages. On the other hand, when the
RPL neighbour node A receives an R-APS (NR, RB) message, it blocks its end of the RPL.
In addition to this, Ethernet ring nodes A to F perform the FDB flush when receiving an
R-APS (NR, RB) message due to the node ID and BPR-based mechanism
В пункте "E" говорится, что после истечения guard таймера и перехода кольца в состояние Pending нода D свой порт разблокирует, а нода C оставляет заблокированным. В пунктах F, G говорится, что только после истечения WTR таймера блокируется RPL линк и нода C разблокирует порт, на котором ранее была детектирована авария.