RRPPP принципиально ли направление primary/secondary портов на транзитах?
Здравствуйте! Разбираюсь с rrpp. RRPP уже поднять на действующей сети. Оборудование в основном HP, HUAWEI. Прочитал все доступные мануалы и остался ряд вопросов, главный из них в заголовке вопроса. В документации написано так: через primary коммутатор шлет hello packet, через secondary принимает. И вроде бы логично звучит. Но у нас на текущей рабочей сети люди вообще не привязывались к направлению этих портов, и всё прекрасно работает. Меня это сильно сбило с толку и для грамотного обслуживания сети мне нужно разобраться с этим вопросом. Подскажите, пожалуйста, люди добрые. У меня есть еще парочка вопросов, так что также буду благодарен если посоветуете целевое сообщество какое-то. Заранее спасибо
В RRPP primary/secondary имеют значение только на мастер-коммутаторе, потому что primary только шлёт, а secondary только принимает. На транзитных коммутаторах health-пакеты просто безусловно коммутируются/пропускаются в обоих направлениях, то есть прописанный для порта primary/secondary элементарно игнорируется. А поскольку в каждом кольце только один мастер-коммутатор, то в режиме штатной работы совершенно неважно, как прописаны на портах роли.
Правильная цепь ролей начинает иметь значение только при нештатных ситуациях на мастере. Ну и при перестройке топологии "на горячую".
Спасибо за ответ! Не могли бы вы немного объяснить логику пересылки health транизтами - они видят, в какой порт он пришел и пересылают в противоположный? Или шлют сразу в оба порта и пакет (при собранном кольце) приходит в два порта мастера одновременно? Также, в доках h3c написано, что linkdown сообщение шлет только тот транзит, чей ВТОРИЧНЫЙ порт упал. Это значит, что при некорректном их расположении время детекта аварии увеличивается до FAIL TIMER мастера.
из вашего ответа я понял, что при нормальной работе кольца это неважно, но мне нужна высокая доступность, чтобы linkdown пришел корректно, а не ждать 30 сек fail timer
Не могли бы вы немного объяснить логику пересылки health транизтами - они видят, в какой порт он пришел и пересылают в противоположный?
Транзит выполняет самую обычную коммутацию пакета внутри VLAN, ему достаточно того, что пакет принадлежит этому VLAN, потому что это именно health-пакет, который ему НЕ предназначен. В отличие от некоторых других типов пакетов, которые не только коммутируются, но и дополнительно обрабатываются.
Также, в доках h3c написано, что linkdown сообщение шлет только тот транзит, чей ВТОРИЧНЫЙ порт упал.
link-down пакет высылается сразу после детекта падения ЛЮБОГО из интерфейсов домена, ессно через второй интерфейс домена.
Akina, я изучал и доки от Huawei и от H3C. Вот как раз в H3C указано, что линкдаун шлет только тот узел, который обнаружил падение ВТОРИЧНОГО линка. От этого, по большому счету, зависит только то, в каком направление от разрыва будет сгенерировано данное сообщение, так что, наверное, большой роли не сыграет на маленьком кольце. Однако, чем больше кольцо, тем принципиальнее с какой стороны от разрыва будет сгенерирован linkdown. claude мне озвучил принцип "транизт должен смотреть первичным портом в сторону мастера по кратчайшему пути", видимо, как раз в соответствии с доками Н3С. Таким образом, можно сделать вывод что в каждом полукольце первичные порты будут направлены в свою сторону, а соединение secondary-secondary будет на ровно противоположной мастеру стороне.
Akina, просто если это делает ЛЮБОЙ транзит, значит при обрыве будет сгенерировано 2 сообщения по разные от обрыва стороны. Я подозреваю, что мастер нормально этот момент обработает, но всё же
просто если это делает ЛЮБОЙ транзит, значит при обрыве будет сгенерировано 2 сообщения по разные от обрыва стороны.
Чёблин? У транзита ДВА интерфейса в домене. Один упал. Рабочий остался ОДИН. Ну как может быть ДВА сообщения, а?
claude мне озвучил принцип "транизт должен смотреть первичным портом в сторону мастера по кратчайшему пути", видимо, как раз в соответствии с доками Н3С. Таким образом, можно сделать вывод что в каждом полукольце первичные порты будут направлены в свою сторону, а соединение secondary-secondary будет на ровно противоположной мастеру стороне.
Бред. Кольцо в RRPP - направленное. При правильной настройке в любой паре соседних коммутаторов кольца primary одного подключается к secondary соседнего. А если направление первичного и вторичного колец различаются, приоритет за первичным.
мне нужна высокая доступность, чтобы linkdown пришел корректно, а не ждать 30 сек fail timer
??? Какой у вас диаметр кольца? средняя задержка управляющего пакета - 1 мс на линк, рекомендуемый диаметр кольца - емнип не более 12 коммутаторов, именно эти значения и определяют время восстановления связности в 50 мс.
Akina, 1. Прочитайте мое сообщение еще раз, там не это написано. Обрыв поделит кольцо на 2 ветки, в каждом транзит обнаружит обрыв и отправит через оставшийся интерфейс линкдаун
2. То есть всё же есть разница в направлении первичного и вторичного портов для быстрого перестроения топологии? Вэтом и заключается мой вопрос
3. Как я уже упомянул, этими цифрами можно принебречь, главное чтобы линкдаун сообщение было доставлено, потому что FAIL TIMER = HELLO TIMER x3 что значительно больше чем пара милисекунд
Обрыв поделит кольцо на 2 ветки, в каждом транзит обнаружит обрыв и отправит через оставшийся интерфейс линкдаун
Да. То есть КАЖДЫЙ коммутатор отправит ОДИН пакет. И да, чисто в теории тот, который пойдёт по более короткой ветке, придёт раньше - причём это совершенно не зависит от того, через какой порт пакет будет отправлен. На практике, с учётом загруженности каналов, всяко может статься. Главное, что дойдёт. Иначе и правда для перестроения топологии придётся ждать детектирования через недошедший Hello.
2. То есть всё же есть разница в направлении первичного и вторичного портов для быстрого перестроения топологии? Вэтом и заключается мой вопрос
До тех пор, пока мастер исправен - никакой разницы.
А если фэйлится именно мастер (причём не линк падает, а сам коммутатор отлетает), то остальные просто обязаны в порядке failover выбрать временно себе нового мастера (а если нет - то протокол говно). И вот тут уже роли портов могут влиять, хотя не могу предсказать точно, как именно. Но вменяемого описания именно такого фэйла мне не попадалось. А предполагать можно вообще что угодно - вплоть до какой-нибудь дури, что они перейдут на STP.
Akina, понял, спасибо за пояснения. К сожалению доки не содержат ответов на некоторые вопросы. В том числе про failover выборы мастера я также слышу впервые, хотя перечитывал мануал как в оригинале так и в переводе.
В том числе про failover выборы мастера я также слышу впервые, хотя перечитывал мануал как в оригинале так и в переводе.
Я тоже не слышал. Но любой протокол устойчивости обязан предусматривать ЛЮБЫЕ типы аварии, и чётко определять, что "это мы лечим вот так, а вон то не лечим вообще".
В данном конкретном случае протокол, скажем, вменяемо рассматривает все варианты пропадания линка (и вариант с дошедшим пакетом, и вариант с пакетом потерянным), а вот аварии с выходом из строя коммутатора не рассматривает ВООБЩЕ. То есть в случае фэйла транзита всё происходящее типа понятно и полностью соответствует случаю отвала отдельного линка. Но вариант, что вышел из строя именно мастер - по-моему, разработчики протокола просто взяли и посчитали такой вариант невозможным теоретически. Или наоборот, постыдились сказать, что такой вариант протокол не обрабатывает.
PS. Я бы вообще отсоветовал бы использовать эти самоляпные проприетарные и мало с чем совместимые протоколы. У меня как раз был RRPP в магистральном кольце, и пришлось от него избавиться, заменив на пусть более медленный. но зато высокосовместимый ERPS. Кстати, это элементарно снизило набор резервного оборудования по стоимости аж втрое, и убрало головняк со временно-аварийными ремонтами, сильно упростив инструкцию.
Mors Clamor, пропадание мастера приводит к тому, что некому слать COMMON/COMPLETE-FLUSH-FDB. Как в этих условиях работает оставшаяся плеть, как передаются и обновляются ARP-таблицы, протокол в принципе не описывает. А это ведь достаточно критичный вопрос.
Mors Clamor, нет, это всё понятно... протокол уже есть, отказываться от него никто не позволит. По счастью, как я понимаю, у вас под рукой в принципе есть несколько единиц оборудования, которое держит этот протокол.
Я просто к тому, что есть смысл собрать стенд на 5-6 коробок да на практике посмотреть, как это выглядит. Помацать в разных режимах и понять, что, как, куда и сколько.
