19:53 Вы говорите, что нет смысла рассылать BPDU, на портах, которые находятся дальше от рута. По идее наоборот, тот порт который ближе к ближе к руту - рут порт, и он уже не передаёт BPDU, ,а вот те которые дальше от рута, те уже передают BPDU, либо свой, либо тот который пришёл от рута
Термины "ближе" и "дальше" в этом контексте использованы применительно ко всем бриджам в одной канальной среде. Среди всех бриджей в канале один будет "ближе" к руту, чем все остальные, и он будет считать себя Designated Bridge (и будет, соответственно, рассылать BPDU). Все остальные бриджи в этом канале будут видеть эти BPDU и понимать, что они сами находятся "дальше" от рута, чем Designated Bridge (и, как следствие, им рассылать BPDU в этом канале смысла нет).
У меня есть гипотеза, что ваши термины "ближе" и "дальше" используются в другом контексте. Я вижу логику в вашем высказывании, если "близость" или "далекость" сравнивать на портах одного и того же бриджа, которые смотрят в разные канальные среды. Там, действительно, Designated Port будет "дальше" от рута, но будет рассылать BPDU. Однако, как уже сказано, в видео контекст другой и сравниваются не порты одного бриджа между собой, а все бриджи в канальной среде (например, в общем проводе).
на 25:30 вы пририсовали пользователя между 4 и 2 свичем, это физически невозможно, в один порт (по схеме десигнейтед 4 свича) воткнуть и коммутатор и ПК. Поясните этот момент, что вы в это время подразумеваете??? Часто вы в схему включаете ПК в разрыв.
1. Физически это более чем возможно. Три варианта, которые позволят с точки зрения STP реализовать подобную структуру: - два свитча соединены коаксиальным проводом 10BASE-5 или 10BASE-2, но в этом же проводе сидят и другие абоненты (собственно, как на картинке и нарисовано) - в разрыв провода между двумя свитчами поставили хаб 10BASE-T и на него же повесили пользователей (электрически эта схема эквивалентна предыдущему варианту, но визуально в такой схеме, конечно же, появится хаб, дополнительное устройство) - в разрыв провода между двумя свитчами поставили свитч без поддержки STP (BPDU будут распространяться точно так же, как в предыдущем пункте) 2. Нет, я не включаю пользователей в разрыв между двумя свитчами. Однако же очень похожую ситуацию можно получить, если включать STP в сети, топология которой достоверно неизвестна (подобные задачи у интеграторов, которым приходится иметь дело с клиентскими сетями, на которые даже у самого клиента нет ни документации, ни представления об их устройстве). Далеко не всегда трасса, которой соединены два свитча в "анархистской" топологии, бывает очевидна, и иногда там может закрасться транзитный тупой свитч с подключенными юзерами. 3. Протокол STP придумали в 1990 году, когда коаксиальные линки с юзерами между бриджами был нормой (а устройства, которые назывались бы коммутаторами, только начали появляться на рынке). В те древние времена задача обслуживания юзеров, сидящих в проводе между двумя бриджами, была суперактуальной. В 2004 году, когда про коаксиалы между свитчами помнили уже только аксакалы, 802.1D превратился в Rapid Spanning Tree именно за счет оптимизации работы на линках точка-точка.
@@NetworkeducationRu огромная вам благодарность! Не ожидал, что кто то ответит) Особенно так развернуто. Дело в том, что я привык видеть устройства на схеме, даже если это хаб. У меня ситуация такая, есть клиент в сети которого сервера с 2 сетевками. Так же есть хабы. Я устал бороться с тем, по колбасит его сеть. Сегодня включил BPDU на всех клиентских портах. Могут ли создавать при определенных условиях такие сервера петли и как их избежать при помощи STP? По моему были случаи, когда такие сервера через себя заворачивали трафик, путем преобразования одного влан в другой с помощью своих 2 сетевок.
Гипотетически сервер может создать петлю. Самый простой пример - взять и забриджевать два интерфейса в Microsoft Windows (www.windowscentral.com/how-set-and-manage-network-bridge-connection-windows-10). Поможет ли STP в вашем конкретном случае - увы, без знания топологии и понимания особенностей конкретной реализации сказать невозможно.
Вы мыслите реалиями сегодняшнего дня, когда все коммутаторы умные, а провода между ними имеют природу точка-точка. STP создавался в 80-х годах, когда Ethernet имел топологию с общей шиной, и в одном проводе могло быть три, пять, сто узлов. Некоторые из этих узлов могли быть бриджами. Тем не менее, очень схожее поведение можно получить и сегодня. Возьмите три (пять, сто) умных свитчей и соедините их через глупый неуправляемый - получите примерно тот же эффект.
Отличное объяснение, спасибо!
Большое спасибо за видео!!! Очень толково, а самое главное на простом языке всё изложено!!!
Здорово!
Spasibo za Trud
esli nemnoqa medlenno abesnili bi bilobi klassno )
Не плохо было бы обновить видео по вопросам сетей относительно сегодняшних требований к сертификации по CCNA и CCNP!!!!
Все круто изложено, единственное не понял как изначально определяется рут
19:53 Вы говорите, что нет смысла рассылать BPDU, на портах, которые находятся дальше от рута. По идее наоборот, тот порт который ближе к ближе к руту - рут порт, и он уже не передаёт BPDU, ,а вот те которые дальше от рута, те уже передают BPDU, либо свой, либо тот который пришёл от рута
Термины "ближе" и "дальше" в этом контексте использованы применительно ко всем бриджам в одной канальной среде. Среди всех бриджей в канале один будет "ближе" к руту, чем все остальные, и он будет считать себя Designated Bridge (и будет, соответственно, рассылать BPDU). Все остальные бриджи в этом канале будут видеть эти BPDU и понимать, что они сами находятся "дальше" от рута, чем Designated Bridge (и, как следствие, им рассылать BPDU в этом канале смысла нет).
У меня есть гипотеза, что ваши термины "ближе" и "дальше" используются в другом контексте. Я вижу логику в вашем высказывании, если "близость" или "далекость" сравнивать на портах одного и того же бриджа, которые смотрят в разные канальные среды. Там, действительно, Designated Port будет "дальше" от рута, но будет рассылать BPDU. Однако, как уже сказано, в видео контекст другой и сравниваются не порты одного бриджа между собой, а все бриджи в канальной среде (например, в общем проводе).
@@NetworkeducationRu короче, это не важно, с какой стороны посмотреть, главное суть понятна. Спасибо за ролики. Странно, что просмотров так мало.
на 25:30 вы пририсовали пользователя между 4 и 2 свичем, это физически невозможно, в один порт (по схеме десигнейтед 4 свича) воткнуть и коммутатор и ПК. Поясните этот момент, что вы в это время подразумеваете??? Часто вы в схему включаете ПК в разрыв.
1. Физически это более чем возможно. Три варианта, которые позволят с точки зрения STP реализовать подобную структуру:
- два свитча соединены коаксиальным проводом 10BASE-5 или 10BASE-2, но в этом же проводе сидят и другие абоненты (собственно, как на картинке и нарисовано)
- в разрыв провода между двумя свитчами поставили хаб 10BASE-T и на него же повесили пользователей (электрически эта схема эквивалентна предыдущему варианту, но визуально в такой схеме, конечно же, появится хаб, дополнительное устройство)
- в разрыв провода между двумя свитчами поставили свитч без поддержки STP (BPDU будут распространяться точно так же, как в предыдущем пункте)
2. Нет, я не включаю пользователей в разрыв между двумя свитчами. Однако же очень похожую ситуацию можно получить, если включать STP в сети, топология которой достоверно неизвестна (подобные задачи у интеграторов, которым приходится иметь дело с клиентскими сетями, на которые даже у самого клиента нет ни документации, ни представления об их устройстве). Далеко не всегда трасса, которой соединены два свитча в "анархистской" топологии, бывает очевидна, и иногда там может закрасться транзитный тупой свитч с подключенными юзерами.
3. Протокол STP придумали в 1990 году, когда коаксиальные линки с юзерами между бриджами был нормой (а устройства, которые назывались бы коммутаторами, только начали появляться на рынке). В те древние времена задача обслуживания юзеров, сидящих в проводе между двумя бриджами, была суперактуальной. В 2004 году, когда про коаксиалы между свитчами помнили уже только аксакалы, 802.1D превратился в Rapid Spanning Tree именно за счет оптимизации работы на линках точка-точка.
@@NetworkeducationRu огромная вам благодарность! Не ожидал, что кто то ответит) Особенно так развернуто. Дело в том, что я привык видеть устройства на схеме, даже если это хаб.
У меня ситуация такая, есть клиент в сети которого сервера с 2 сетевками. Так же есть хабы. Я устал бороться с тем, по колбасит его сеть. Сегодня включил BPDU на всех клиентских портах. Могут ли создавать при определенных условиях такие сервера петли и как их избежать при помощи STP? По моему были случаи, когда такие сервера через себя заворачивали трафик, путем преобразования одного влан в другой с помощью своих 2 сетевок.
Гипотетически сервер может создать петлю. Самый простой пример - взять и забриджевать два интерфейса в Microsoft Windows (www.windowscentral.com/how-set-and-manage-network-bridge-connection-windows-10).
Поможет ли STP в вашем конкретном случае - увы, без знания топологии и понимания особенностей конкретной реализации сказать невозможно.
Крайне недоступно объясняете. Да и примеры весьма странные. Как вы врезали в линк между коммутаторами ещё несколько коммутаторов?
Вы мыслите реалиями сегодняшнего дня, когда все коммутаторы умные, а провода между ними имеют природу точка-точка. STP создавался в 80-х годах, когда Ethernet имел топологию с общей шиной, и в одном проводе могло быть три, пять, сто узлов. Некоторые из этих узлов могли быть бриджами.
Тем не менее, очень схожее поведение можно получить и сегодня. Возьмите три (пять, сто) умных свитчей и соедините их через глупый неуправляемый - получите примерно тот же эффект.
@@NetworkeducationRu спасибо за информацию. Не хотел показаться грубым.