Комментарии 32
хм. интересная тематика, плюс
Скажите, пожалуйста, в случае подключения access свитчей по кольцу, вы настраиваете приоритеты distribution свитча для того чтобы он стал корневым свитчом STP? Как вы контролируете, что бы не заблокировался порт от distribution свитча к access?
Я, конечно ни разу не CCIE, но попробую ответить на ваш вопрос.
PVST выставляет приоритеты для per-vlan basis, т.е. если впринципе поделить все vlan'ы, которые присутствуют на access свичах поровну между distribution свичами и назначить их соответственно primary (для тех, которые должны терминироваться на этих свичах) и secondary root bridge (для тех vlan, svi которых сидят в HSRP Standby и ждут своего звёздного часа ), то сами по себе порты блокироваться не будут. Будут блокироваться отдельные vlan'ы
В зависимости от того, как вы хотите использовать кольцевую топологию, назначением Pri\Sec Root на конкретные vlan можно добиться как и распределения vlan с конкретного Access SW между 2 аплинками и 2-мя Distribution SW, так и распределения в режиме failover.
PVST выставляет приоритеты для per-vlan basis, т.е. если впринципе поделить все vlan'ы, которые присутствуют на access свичах поровну между distribution свичами и назначить их соответственно primary (для тех, которые должны терминироваться на этих свичах) и secondary root bridge (для тех vlan, svi которых сидят в HSRP Standby и ждут своего звёздного часа ), то сами по себе порты блокироваться не будут. Будут блокироваться отдельные vlan'ы
В зависимости от того, как вы хотите использовать кольцевую топологию, назначением Pri\Sec Root на конкретные vlan можно добиться как и распределения vlan с конкретного Access SW между 2 аплинками и 2-мя Distribution SW, так и распределения в режиме failover.
Не совсем понял, что значит «Будут блокироваться отдельные vlan'ы». Блокируются порты, а не VLAN'ы. Хотя, может, я просто неверно вас понял. И что вы подразумеваете под режимом failover?
В статье написано, что VLAN'ы терминируются на distribution свитчах. Соответственно, есть два возможных варианта:
1) Наиболее вероятный: канал между двумя distribution свитчам является каналом L3. В таком случае, никакого кольца нет. Один VLAN простирается от одного distribution свитча до другого, через пару access свитчей. Никаких петель нет, STP ничего не блокирует. Один из distribution свитчей выбирается STP root'ом, и HSRP active для одной группы пользователей, и standby'ем для второй группы пользователей (для балансировки нагрузки). Соответственно, второй distribution свитч становится active'ом для второй группы пользователей, и standby'ем для первой.
2) Второй вариант — если канал между двумя distribution свитчами является каналом второго уровня. Тогда он должен становиться транком, и для каждого VLAN мы получаем топологию кольца. Соответственно, нужно сделать так, что бы заблокированным оказался один из портов между access свитчом. Если же заблокируется порт между distribution и access свитчом, то получится что весь траффик идет через один distribution свитч, что не есть хорошо. Вот про подобный вариант я и спрашивал.
В статье написано, что VLAN'ы терминируются на distribution свитчах. Соответственно, есть два возможных варианта:
1) Наиболее вероятный: канал между двумя distribution свитчам является каналом L3. В таком случае, никакого кольца нет. Один VLAN простирается от одного distribution свитча до другого, через пару access свитчей. Никаких петель нет, STP ничего не блокирует. Один из distribution свитчей выбирается STP root'ом, и HSRP active для одной группы пользователей, и standby'ем для второй группы пользователей (для балансировки нагрузки). Соответственно, второй distribution свитч становится active'ом для второй группы пользователей, и standby'ем для первой.
2) Второй вариант — если канал между двумя distribution свитчами является каналом второго уровня. Тогда он должен становиться транком, и для каждого VLAN мы получаем топологию кольца. Соответственно, нужно сделать так, что бы заблокированным оказался один из портов между access свитчом. Если же заблокируется порт между distribution и access свитчом, то получится что весь траффик идет через один distribution свитч, что не есть хорошо. Вот про подобный вариант я и спрашивал.
В PVST блокируются именно VLAN.
PVST запускает отдельную сущность STP для каждого VLAN. Соответственно, для одной физической конфигурации у каждого VLAN'а root'ом могут быть выбраны разные свитчи и заблокированы разные порты. То есть один и тот же физический порт на свитче может быть заблокирован для одного VLAN, и не заблокирован для другого VLAN. Вы это подразумеваете под фразой «В PVST блокируются именно VLAN»?
Ну, для начала подключать access-свитчи кольцом — плохо. Потому как будет высока занятость линков в кольце. Лучше как на рисунках в статье — треугольничками до двух core/distribution.
А так — да, стандартными средствами контролируется кто будет root/secondary root. Всегда жестко задаете приоритеты свитчей, вес линков и используете «guard root», «guard loop». В случае с подключением кольцом будет заблокирован один из портов в цепочке access-свитчей. В случае с треугольничком — всегда блокируется линк от access до secondary-root, но плохая утилизация линков обходится использованием pvst/mst: для разных vlan-ов роли root/secondary root меняются местами (приоритеты distribution свитчей в разных вланах — разные). Например для четных vlan root'ом будет свитч слева, для нечетных — справа. Соотв. для четных вланов в нормальной ситуации (когда все линки живы) трафик бегает по левому плечу, для нечетных — по правому. Если клиентских вланов больше 3х — утилизация будет близкой к равномерной.
А так — да, стандартными средствами контролируется кто будет root/secondary root. Всегда жестко задаете приоритеты свитчей, вес линков и используете «guard root», «guard loop». В случае с подключением кольцом будет заблокирован один из портов в цепочке access-свитчей. В случае с треугольничком — всегда блокируется линк от access до secondary-root, но плохая утилизация линков обходится использованием pvst/mst: для разных vlan-ов роли root/secondary root меняются местами (приоритеты distribution свитчей в разных вланах — разные). Например для четных vlan root'ом будет свитч слева, для нечетных — справа. Соотв. для четных вланов в нормальной ситуации (когда все линки живы) трафик бегает по левому плечу, для нечетных — по правому. Если клиентских вланов больше 3х — утилизация будет близкой к равномерной.
А не логичнее сделать линк между двумя distribution свитчам маршрутизируемым? Все равно маршрутизацией занимается distribution уровень. Таким образом, в случае топологии «треугольничком» (хм, забавный термин), оба линка от access свитча будут активными и равномерно утилизировать траффик. Или в таком варианте есть какие-то недостатки?
Ну, в общем L3 между distribution — это и есть best practice. И протокол GLBP в качестве first-hop redundancy.
вот кстати, специально для вас (да и для всех интересующихся) нашел хороший докладик на эту и смежные темы с Cisco Networkers 2005 — Campus network multilayer architecture and design guidelines:
dl.dropbox.com/u/5547822/Cisco%20-%20campus%20multilayer%20design%20guide.pdf
dl.dropbox.com/u/5547822/Cisco%20-%20campus%20multilayer%20design%20guide.pdf
Спасибо. Буду изучать
И правда, на 56-й странице как раз рассмотрен случай подключения по кольцу (так называемый daisy chaining). В случае, если линк между двумя access свитчами упадет, трафик к пользователю будет иметь 50% шанс не дойти до адресата (так как обратный трафик идет через один distribution свитч)
Производительность. Конечно, можно обеспечить default gateway redundancy и для SVI физических лиц, но в случае падения одного из distribution свичей — не факт, что второй сможет тянуть одновременно и свою нагрузку, а нагрузку «упавшего» в полном обїеме.
Для такой балансировки приятнее использовать MSTP имхо.
У меня на доступе практически как вы описали: 50% с одного плеча, 50% с другого. Использую MSTP, для меньшего кол-ва BPDU и легкости администрирования.
У меня на доступе практически как вы описали: 50% с одного плеча, 50% с другого. Использую MSTP, для меньшего кол-ва BPDU и легкости администрирования.
Очень и очень. У меня, как у человека никогда не работавшего с сетями такого размаха, в подсознании всегда было предчуствие, что конфиги девайсов в таких сетях какие-то «другие», хоть и сознание говорит, что команды-то вообщем теже самые. Очень приятно было их читать, а главное понимать :)
В сервис-полиси название фирмы уберите…
Вопросы.
1. Я хочу н-р МТУ=1600. Можете? :)
2. mac access-group filtermac in. Я не хочу как-то согласовывать с вами работы по замене своего CE, можно не привязывать моё устройство?
В целом приятно что большие дядьки строят также как я/мы, только девайсы чуть попроще и PE включает в себя функции Core-уровня :)
Вопросы.
1. Я хочу н-р МТУ=1600. Можете? :)
2. mac access-group filtermac in. Я не хочу как-то согласовывать с вами работы по замене своего CE, можно не привязывать моё устройство?
В целом приятно что большие дядьки строят также как я/мы, только девайсы чуть попроще и PE включает в себя функции Core-уровня :)
Отлично. Как там твой ccie статус кстати
хм...Catalyst 4506 на доступ?
Такие сети провайдера обслуживают только юр.лиц?
Или для физиков используется то же оборудование?
Просто сколько видел провайдерские сети в жилых районах, то на доступе это обычно D-link, в лучшем случае Telesyn, а то и вовсе «неуправляемые» коммутаторы.
Такие сети провайдера обслуживают только юр.лиц?
Или для физиков используется то же оборудование?
Просто сколько видел провайдерские сети в жилых районах, то на доступе это обычно D-link, в лучшем случае Telesyn, а то и вовсе «неуправляемые» коммутаторы.
Tier 1 — это не домашний провайдер.
ru.wikipedia.org/wiki/Tier_1
ru.wikipedia.org/wiki/Tier_1
Для физических лиц используются точно те же сети доступа и точно то же оборудование — там даже на картинках были нарисованы residential customer-ы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура Aggregation-Access сети крупных провайдеров