Комментарии 41
НЛО прилетело и опубликовало эту надпись здесь
Я вот всегда переводил Spanning Tree как «покрывающее дерево».
Отлично показывает, практически секундная сходимость, быстрее только сходимость роутинга с субсекундными таймерами.
Есть ещё специальные протоколы для кольцевых топологий (в которых как раз RSTP работает не очень хорошо и при неудачном стечении обстоятельств может сходится десяток-другой секунд), например REP или EAPS с временем сходимости около 100 ms или даже меньше.
А что такое «роутинг с субсекундными таймерами»?
Прекрасная статья. Очень хорошо и понятно.
А скажите, какой коммутатор поддерживает over9000 vlan'ов.
А скажите, какой коммутатор поддерживает over9000 vlan'ов.
Может быть стоило в статье рассказать как STP настраивается?
Хоть и далек от таких задач, прочитал запоем, очень понятно пишите
Такая благодатная тема для рассказа и так мало написано. По сути перевод статьи с английской википедии с использование языка луркмоара.
Где рассказ, чем детально отличаются STP,RSTP и MSTP, что когда применять, вопросы совместимости протоколов, вопросы безопасности. Что такое edge/portfast порты, чем вредны частые перестроения stp топологии…
в общем ждем от вас больше креатива
Где рассказ, чем детально отличаются STP,RSTP и MSTP, что когда применять, вопросы совместимости протоколов, вопросы безопасности. Что такое edge/portfast порты, чем вредны частые перестроения stp топологии…
в общем ждем от вас больше креатива
Вот я лично жду от Вас такую статью. Вперед.
Если есть общественный интерес к теме, то я готов.
Если уж совсем исчерпывающе рассматривать кольцевые топологи, то и про L3-свичи было бы полезно написать и про Link aggregation. Темы, как мне кажется, немного интереснее, т.к. STP — это все же холодный резерв со всеми вытекающими недостатками.
Если уж брать кольцевые топологии, то надо рассмотреть хотя бы парочку непосредственно кольцевых топологий.
И вы путаете тёплое с мягким. Во-первых, STP, RSTP, кольцевые топологии, не избавят Ethernet от необходимости в холодном резерве. Точнее, сейчас появляются такие технологии, но там используются свои фишки и нужны они не совсем для «нормальной» работы сети.
Агрегация каналов позволяет добиться горячего резерва на отдельно взятом канале и может использоваться вместе с STP и прочим, но никак не заменяет его.
И вы путаете тёплое с мягким. Во-первых, STP, RSTP, кольцевые топологии, не избавят Ethernet от необходимости в холодном резерве. Точнее, сейчас появляются такие технологии, но там используются свои фишки и нужны они не совсем для «нормальной» работы сети.
Агрегация каналов позволяет добиться горячего резерва на отдельно взятом канале и может использоваться вместе с STP и прочим, но никак не заменяет его.
Если уж брать кольцевые топологии, то надо рассмотреть хотя бы парочку непосредственно кольцевых топологий.
Вполне здравое предложение.
Агрегация каналов позволяет добиться горячего резерва на отдельно взятом канале и может использоваться вместе с STP и прочим, но никак не заменяет его.
Это классическая зашоренность. Посмотрите на SMLT и vPC — собственно, расширения технологий агрегации каналов MLT и PortChannel. Описание того же vPC даже имеет характерный заголовок. Уже давно агрегация каналов не используется исключительно для увеличения пропускной способности.
На счет теплого с мягким не понял, честно.
STP, RSTP, кольцевые топологии, не избавят Ethernet от необходимости в холодном резерве.
Это я где такое писал? Я напротив, говорил, что это и есть основной недостаток STP (как и время сходимости сети), что избыточная инфраструктура в кольцевой топологии лежит мертвым грузом, до тех пор пока не произойдет отказ.
Это классическая зашоренность. Посмотрите на SMLT и vPC — собственно, расширения технологий агрегации каналов MLT и PortChannel. Описание того же vPC даже имеет характерный заголовок.
Ну раз Вы про расширения агрегации, то так бы и написали. Сама Link Aggregation IEEE 802.3ad, насколько мне известно, не используется для связи с разными узлами. Только для увеличения пропускной способности + резерв линка. И вообще, SMLT и vPC — проприетарные протоколы.
Это я где такое писал? Я напротив, говорил, что это и есть основной недостаток STP (как и время сходимости сети), что избыточная инфраструктура в кольцевой топологии лежит мертвым грузом, до тех пор пока не произойдет отказ.
Ну это же недостаток не STP, а самого Ethernet. STP — просто решение.
PS. Да почему Вы всё время говорите о кольцевой топологии??
А так — пишите, конечно. Лично мне было бы интересно.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Потому что коммутаторы работают на втором уровне эталонной сетевой модели с протоколом ethernet, а не с протоколом ip. Механизм ttl — часть ip протокола, в ethernet он отсутствует.
НЛО прилетело и опубликовало эту надпись здесь
Пока я писал ответ, вы свой уже опубликовали ))
Могу еще добавить, что ttl не спасет от получения дублированных копий пакетов и от самой проблемы размножения пакетов. просто немного снизит эффект. Чтобы ttl работал, добавь мы его в ethernet заголовки, необходимо добавить еще и идентификатор пакета, чтобы свитчи могли как-то отслеживать, пропускали они уже такой пакет или нет. Все это очевидно здорово усложнило бы протокол 2го уровня, который должен быть максимально простым.
Могу еще добавить, что ttl не спасет от получения дублированных копий пакетов и от самой проблемы размножения пакетов. просто немного снизит эффект. Чтобы ttl работал, добавь мы его в ethernet заголовки, необходимо добавить еще и идентификатор пакета, чтобы свитчи могли как-то отслеживать, пропускали они уже такой пакет или нет. Все это очевидно здорово усложнило бы протокол 2го уровня, который должен быть максимально простым.
Здесь еще обязательно-преобязательно должно быть это:
Algorhyme
I think that I shall never see
a graph more lovely than a tree.
A tree whose crucial property
is loop-free connectivity.
A tree that must be sure to span
so packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
then bridges find a spanning tree.
эпиграф к статье Радии Перльман, в которой был впервые описан изобретенный ею Spanning Tree Protocol
Algorhyme
I think that I shall never see
a graph more lovely than a tree.
A tree whose crucial property
is loop-free connectivity.
A tree that must be sure to span
so packets can reach every LAN.
First, the root must be selected.
By ID, it is elected.
Least-cost paths from root are traced.
In the tree, these paths are placed.
A mesh is made by folks like me,
then bridges find a spanning tree.
эпиграф к статье Радии Перльман, в которой был впервые описан изобретенный ею Spanning Tree Protocol
Вообще, я немного не понял при чем тут «Закольцованные сети», указанные в заголовке. Подумалось, что в статье будут рассматриваться какие-нибудь кольцевые топологии заодно.
MSTP помимо этого нужен для того чтобы разбить сеть на субдомены и запустить отдельный STP в каждом из них и еще один — между субдоменами. Чтобы изменения топологии в одном сегменте меньше затрагивали всю сеть.
настраивал колечко RSTP на D-link'ах 3526, сходимость меньше секунды, в кольце шесть свитчей, пока проблем не обнаружено
И сколько вы ставили Hello-time?
Совершенно верно, RSTP может сходится очень быстро. Ни одного пинга не пропадёт.
Но есть условие — линк должен упасть совсем. Тогда смысла ждать 3 хеллоу, конечно, не будет, и свитч переключит сразу.
А вот если линк жив, а BPDU перестали идти — фатальный сбой совсем не очевиден. Может, канал забит где-то. Или процессор на той стороне загрузили так жестоко, что команду генерации и отправки BPDU никак не отработает. А может, конечно, и Root Bridge умер. Так что ждём, а вдруг разродится.
Но есть условие — линк должен упасть совсем. Тогда смысла ждать 3 хеллоу, конечно, не будет, и свитч переключит сразу.
А вот если линк жив, а BPDU перестали идти — фатальный сбой совсем не очевиден. Может, канал забит где-то. Или процессор на той стороне загрузили так жестоко, что команду генерации и отправки BPDU никак не отработает. А может, конечно, и Root Bridge умер. Так что ждём, а вдруг разродится.
когда я читаю такую статью, остается непонятным одно: зачем ее писать?
1) Это новая технология, которая мало где описана?
2) Эта технология, по которой мало материала на русском языке?
3) Это личный опыт или подводные камни в какой-то известной технологии?
4) Это особенности внедрения в каком-то конкретном окружении?
Ответ на эти вопросы: «нет». И какой смысл было это писать/переводить? просто чтобы все посмотрели, «как я пишу и могу излагать общеизвестные мысли»?
ничего не имею против автора лично и тех, кому статья понравилась. Но все же это лишено смысла.
1) Это новая технология, которая мало где описана?
2) Эта технология, по которой мало материала на русском языке?
3) Это личный опыт или подводные камни в какой-то известной технологии?
4) Это особенности внедрения в каком-то конкретном окружении?
Ответ на эти вопросы: «нет». И какой смысл было это писать/переводить? просто чтобы все посмотрели, «как я пишу и могу излагать общеизвестные мысли»?
ничего не имею против автора лично и тех, кому статья понравилась. Но все же это лишено смысла.
Я такие статьи называю якорными, они дают возможность понять в общих чертах, что за технология и для чего она. Зародить интерес, если можно так сказать.
Тем более автор рельно хорошо донес материал, лично мне бы хотелось увидеть продолжение. По тому как сам так доходчиво обьяснить не могу, а коллеги иногда спрашивают.
Тем более автор рельно хорошо донес материал, лично мне бы хотелось увидеть продолжение. По тому как сам так доходчиво обьяснить не могу, а коллеги иногда спрашивают.
В целом нормально хорошо даже написано для обзора.
Да только по нынешним временам пора писать статьи про то, как от STP избавиться, а не зачем он нужен. Повсеместная кластеризация свичей с возможностью объединять в LAG линков с разных устройств — как раз для этого.
А тот кто траблшутил STP разок-другой в сети из хотя бы нескольких десятков устройств, размазанной по большой географии — тот и сам все знает :) Но раньше выбора не было, а сегодня вот есть.
Да только по нынешним временам пора писать статьи про то, как от STP избавиться, а не зачем он нужен. Повсеместная кластеризация свичей с возможностью объединять в LAG линков с разных устройств — как раз для этого.
А тот кто траблшутил STP разок-другой в сети из хотя бы нескольких десятков устройств, размазанной по большой географии — тот и сам все знает :) Но раньше выбора не было, а сегодня вот есть.
Даже несмотря на то, что статья написана не про rocket science технологию, должен отметить, что у вас отличный слог. Знаете, эдакий слог учителя, заинтересованного в своем предмете, да к тому же способного донести свои знания в удобоваримой форме до адресата.
Довольно ценная способность для технарей. Практикуйтесь и далее, вам приятно, кому-то полезно.
Довольно ценная способность для технарей. Практикуйтесь и далее, вам приятно, кому-то полезно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Закольцованные сети, или зачем нам STP