Comments 49
Спасибо!
Так и знал, что «падение» сети — это проделки Бендера =)
Не заметил один момент, совершенно критический, и почему-то игнорируемый во всех курсах циски.
Portfast на нагруженных свитчах смертельно опасен!
Суть в следующем.
1) На любых коммутаторах BPDU обрабатываются программно.
2) Частота рассылки BPDU — по дефолту 2 секунды.
3) При втыкании патч-корда порт переходит в forwarding мгновенно.
По меркам коммутатора, через который проходит много (десятков) гигабит, 2 секунды — вечность. За это время мозги свитчу выносятся напрочь, и он уже не может загасить порт (errdisable в случае BPDU Guard или просто stp blocking — неважно), ресурсов для обработки BPDU нет, ибо большинство броадкастов в сети — ARP пакеты, долетающие до CPU свитча. И вот у нас шторм по всему L2 сегменту, который не хочет прекращаться сам по себе.
Это не голая теория, я сам однажды на это нарвался (как дебил сказал человеку «воткни новый свитч в любые два порта»).
Понятно, что на аксессной пользовательской железке с парой сотен мегабит и 100мб интерфейсами до пользователей такая катастрофа маловероятна, я больше про ЦОДы говорю.
Потому ОБЯЗАТЕЛЬНО задействовать Storm Control везде, где только можно. Он реализован аппаратно, и он позволяет коммутатору успешно работать и при шторме. Ведь один из самых мерзких моментов шторма — то, что и добраться до самого свитча при отсутствии out-of-band management крайне непросто.
Кстати — как минимум cat6500 прекрасно отзывается по консоли даже когда шторм выжрал все ресурсы.
Portfast на нагруженных свитчах смертельно опасен!
Суть в следующем.
1) На любых коммутаторах BPDU обрабатываются программно.
2) Частота рассылки BPDU — по дефолту 2 секунды.
3) При втыкании патч-корда порт переходит в forwarding мгновенно.
По меркам коммутатора, через который проходит много (десятков) гигабит, 2 секунды — вечность. За это время мозги свитчу выносятся напрочь, и он уже не может загасить порт (errdisable в случае BPDU Guard или просто stp blocking — неважно), ресурсов для обработки BPDU нет, ибо большинство броадкастов в сети — ARP пакеты, долетающие до CPU свитча. И вот у нас шторм по всему L2 сегменту, который не хочет прекращаться сам по себе.
Это не голая теория, я сам однажды на это нарвался (как дебил сказал человеку «воткни новый свитч в любые два порта»).
Понятно, что на аксессной пользовательской железке с парой сотен мегабит и 100мб интерфейсами до пользователей такая катастрофа маловероятна, я больше про ЦОДы говорю.
Потому ОБЯЗАТЕЛЬНО задействовать Storm Control везде, где только можно. Он реализован аппаратно, и он позволяет коммутатору успешно работать и при шторме. Ведь один из самых мерзких моментов шторма — то, что и добраться до самого свитча при отсутствии out-of-band management крайне непросто.
Кстати — как минимум cat6500 прекрасно отзывается по консоли даже когда шторм выжрал все ресурсы.
очень ценно, спасибо
Про это можно почитать например тут: blog.ioshints.info/2012/04/stp-loops-strike-again.html
И еще момент. Хорошая сеть — та сеть, где вообще нет STP колец, и ни один линк не блокируется, с сохранением полной отказоустойчивости (STP задействован лишь в качестве предохранительного механизма). Обычно используют агрегацию линков плюс технологии, позволяющие завязать один port-channel на двух или более разных шасси (стеки на 3750, VSS на cat6500, vPC на нексусах и т.д. — у каждого вендора есть нечто подобное). Хардкор — полноценный роутинг на L2, TRILL и протоколы на его основе (у циски — Fabricpath). Но его пока мало где встретишь, и то кроме ЦОДов он нигде не используется.
И еще момент. Хорошая сеть — та сеть, где вообще нет STP колец, и ни один линк не блокируется, с сохранением полной отказоустойчивости (STP задействован лишь в качестве предохранительного механизма). Обычно используют агрегацию линков плюс технологии, позволяющие завязать один port-channel на двух или более разных шасси (стеки на 3750, VSS на cat6500, vPC на нексусах и т.д. — у каждого вендора есть нечто подобное). Хардкор — полноценный роутинг на L2, TRILL и протоколы на его основе (у циски — Fabricpath). Но его пока мало где встретишь, и то кроме ЦОДов он нигде не используется.
на хабре была интересная статья на этот счет. В комментариях нешуточные дебаты. В идеале- да, согласен. Но суровая реальность сурова.
В комментариях нешуточные дебаты.
Да там даже обсуждать нечего. Любой, кто говорит, что STP хорош хоть чем-то кроме дешевого решения для организации базовой избыточности либо в качестве предохранителя, является ослом.
Хотя смотрю, кому-то хватило мозгов сделать no spanning-tree vlan X, раз как бы теоретически колец нет. Ну-ну… Никто ведь не говорит, что STP надо отключать. Просто он не должен ничего никогда блокировать кроме как на полминуты максимум при появлении физики.
Да там даже обсуждать нечего. Любой, кто говорит, что STP хорош хоть чем-то кроме дешевого решения для организации базовой избыточности либо в качестве предохранителя, является ослом.
Хотя смотрю, кому-то хватило мозгов сделать no spanning-tree vlan X, раз как бы теоретически колец нет. Ну-ну… Никто ведь не говорит, что STP надо отключать. Просто он не должен ничего никогда блокировать кроме как на полминуты максимум при появлении физики.
А не подскажите, как CCNP, что на нужность\не нужность STP говорит 642-813 SWITCH? А то я пока на 642-902 ROUTE застрял.
Или вышеописанная вами теория и есть, то что рекомендует cisco?
Спасибо за ответ
Или вышеописанная вами теория и есть, то что рекомендует cisco?
Спасибо за ответ
в 642-813 половина — это STP и его вариации. содержимое топика — необходимый, но недостаточный минимум для сдачи.
Удачи с роутингом, больше практикуйтесь!
Удачи с роутингом, больше практикуйтесь!
Понятия не имею про SWITCH, я когда-то BCMSN сдавал. Но тогда данный экзамен был не архитектурным, а техническим. Думаю, с тех пор мало что изменилось. И крайне сомневаюсь, что в SWITCH будут вопросы про VSS/vPC, ибо у человека, не администрирующего 6500/N5k, мало шансов потрогать эти технологии.
Для решения архитектурных вопросов следует выйти за рамки сертификаций и читать SRND, где куда более актуальная информация. Вот например про «отказ от STP»:
www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html#wp1044510
Да и вообще советую прочитать всю эту статью, там много полезной информации.
Для решения архитектурных вопросов следует выйти за рамки сертификаций и читать SRND, где куда более актуальная информация. Вот например про «отказ от STP»:
www.cisco.com/en/US/docs/solutions/Enterprise/Data_Center/DC_3_0/DC-3_0_IPInfra.html#wp1044510
Да и вообще советую прочитать всю эту статью, там много полезной информации.
На том BCMSN (SWITCH) что был я этот момент ни разу не игнорировался. Но даже без него понятно, что
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc… to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
при включении оного — не просто так написан.
Отсюда вывод — вы включили portfast там где включать его было нельзя, получив тот самый temporary bridging loop, и дело тут вовсе не в нагрузке…
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc… to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
при включении оного — не просто так написан.
Отсюда вывод — вы включили portfast там где включать его было нельзя, получив тот самый temporary bridging loop, и дело тут вовсе не в нагрузке…
«can cause temporary bridging loops»
Именно что скорее «constant». Циска на моей памяти не говорила, что подобный луп может вынести весь L2 сегмент до того момента, когда администратор руками разъединит кольцо, а не на 2 секунды до первой BPDU.
Мне на самом деле тогда сильно «повезло». Местный умудрился попасть в 2 из 4-х портов, в которые попадать было нельзя.
«вы включили portfast там где включать его было нельзя»
Немного неправильный подход. Сеть должна быть отказо- и дуракоустойчивой. То есть вытыкание или втыкание любого проводка не должно приводить к катастрофе. А то получается на «попал в аварию и не сработала подушка» ответ «не надо было попадать в аварию».
У нас на пользовательском аксессе раз в пару месяцев BPDU guard блокирует порты, потому что кто-то умный втыкает торчащий из розетки патч-корд в соседнюю розетку. Суть моего комментария сводится к тому, что не следует полагаться на механизмы STP в этом случае. Ну ладно, на пользовательском порту можно сказать «sw port-security max 3», это должно помочь, а вот в виртуализированном ЦОДе с этим куда сложнее. Потому всегда нужны дополнительные меры защиты. Но: они не всегда поддерживаются. Взять Nexus 2000 — у них нет никакого storm control. То есть кто-то соединил соседние порты патч-кордом, и минимум кусок сети с большой вероятностью лег.
Именно что скорее «constant». Циска на моей памяти не говорила, что подобный луп может вынести весь L2 сегмент до того момента, когда администратор руками разъединит кольцо, а не на 2 секунды до первой BPDU.
Мне на самом деле тогда сильно «повезло». Местный умудрился попасть в 2 из 4-х портов, в которые попадать было нельзя.
«вы включили portfast там где включать его было нельзя»
Немного неправильный подход. Сеть должна быть отказо- и дуракоустойчивой. То есть вытыкание или втыкание любого проводка не должно приводить к катастрофе. А то получается на «попал в аварию и не сработала подушка» ответ «не надо было попадать в аварию».
У нас на пользовательском аксессе раз в пару месяцев BPDU guard блокирует порты, потому что кто-то умный втыкает торчащий из розетки патч-корд в соседнюю розетку. Суть моего комментария сводится к тому, что не следует полагаться на механизмы STP в этом случае. Ну ладно, на пользовательском порту можно сказать «sw port-security max 3», это должно помочь, а вот в виртуализированном ЦОДе с этим куда сложнее. Потому всегда нужны дополнительные меры защиты. Но: они не всегда поддерживаются. Взять Nexus 2000 — у них нет никакого storm control. То есть кто-то соединил соседние порты патч-кордом, и минимум кусок сети с большой вероятностью лег.
> Циска на моей памяти не говорила, что подобный луп может вынести весь L2 сегмент
Циска вроде бы никогда не умалчивала того факта что bridging loop — это то чего стоит избегать любой ценой.
>> «вы включили portfast там где включать его было нельзя»
> Немного неправильный подход. Сеть должна быть отказо- и дуракоустойчивой.
Вы сами отключии защиту от дурака там где этого было делать нельзя. portfast по умолчанию не задействован на всех портах. При его включении в консоли отдает ворнинг с капсом CAUTION. Таким образом вы сняли ремни безопасности, убрали подушку, — и тапку в пол. А потом заявляете что, мол, ездить на машине смертельно опасно…
> У нас на пользовательском аксессе раз в пару месяцев BPDU guard блокирует порты, потому что кто-то умный втыкает торчащий из розетки патч-корд в соседнюю розетку. Суть моего комментария сводится к тому, что не следует полагаться на механизмы STP в этом случае.
Получается, portfast у вас на access портах отключен, раз там bpdu летят?
Взять Nexus 2000 — у них нет никакого storm control. То есть кто-то соединил соседние порты патч-кордом, и минимум кусок сети с большой вероятностью лег.
Если есть вероятность образование петли, то отключать portfast и глушить там stp — преступление против человечества. И рано поздно это даст по голове. Еще раз — should only be enabled on ports connected to a single host. А сдуру можно много чего сломать…
Циска вроде бы никогда не умалчивала того факта что bridging loop — это то чего стоит избегать любой ценой.
>> «вы включили portfast там где включать его было нельзя»
> Немного неправильный подход. Сеть должна быть отказо- и дуракоустойчивой.
Вы сами отключии защиту от дурака там где этого было делать нельзя. portfast по умолчанию не задействован на всех портах. При его включении в консоли отдает ворнинг с капсом CAUTION. Таким образом вы сняли ремни безопасности, убрали подушку, — и тапку в пол. А потом заявляете что, мол, ездить на машине смертельно опасно…
> У нас на пользовательском аксессе раз в пару месяцев BPDU guard блокирует порты, потому что кто-то умный втыкает торчащий из розетки патч-корд в соседнюю розетку. Суть моего комментария сводится к тому, что не следует полагаться на механизмы STP в этом случае.
Получается, portfast у вас на access портах отключен, раз там bpdu летят?
Взять Nexus 2000 — у них нет никакого storm control. То есть кто-то соединил соседние порты патч-кордом, и минимум кусок сети с большой вероятностью лег.
Если есть вероятность образование петли, то отключать portfast и глушить там stp — преступление против человечества. И рано поздно это даст по голове. Еще раз — should only be enabled on ports connected to a single host. А сдуру можно много чего сломать…
Вы сами отключии защиту от дурака
Ну вот представим себе, что portfast на порту абсолютно необходим. Некая система не может ждать по полминуты после поднятия линка. Выходит, кто-то соединил два порта — и приплыли…
Получается, portfast у вас на access портах отключен, раз там bpdu летят?
Вы путаете portfast с bpdufilter.
#show spanning-tree interface fa4/10 detail
Port 202 (FastEthernet4/10) of VLAN0200 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.202.
Designated root has priority 32968, address 001a.a18b.bec0
Designated bridge has priority 32968, address 001a.a18b.bec0
Designated port id is 128.202, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 0
The port is in the portfast mode
Link type is point-to-point by default
Bpdu guard is enabled by default
BPDU: sent 1099568, received 0
Вот здоровый аксессный порт. Если соединить его с fa4/11, то с вероятностью 99,999% fa4/10 уйдет в blocking, сразу после получения BPDU, и пользователи ничего не заметят.
Еще раз — should only be enabled on ports connected to a single host. А сдуру можно много чего сломать…
Если человек полагается на «авось», т.е. надеется на то, что никто не соединит соседние порты патч-кордом, то ему вообще нечего делать в IT. Необходимо заранее предусмотреть любые возможные сценарии, ведущие к аварии, и предпринять меры по недопущению как можно большего числа этих аварий. И всегда исходить из того, что пользователь — идиот; вспышки на солнце происходят каждый день; глюк в софте на сетевом железе случается раз в два дня и т.д.
Вы же явно сторонник подхода «если система падает от чиха, то надо запретить чихать, а не устранить источник влияния чиха на стабильность». Так не бывает.
Ну вот представим себе, что portfast на порту абсолютно необходим. Некая система не может ждать по полминуты после поднятия линка. Выходит, кто-то соединил два порта — и приплыли…
Получается, portfast у вас на access портах отключен, раз там bpdu летят?
Вы путаете portfast с bpdufilter.
#show spanning-tree interface fa4/10 detail
Port 202 (FastEthernet4/10) of VLAN0200 is designated forwarding
Port path cost 19, Port priority 128, Port Identifier 128.202.
Designated root has priority 32968, address 001a.a18b.bec0
Designated bridge has priority 32968, address 001a.a18b.bec0
Designated port id is 128.202, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 0
The port is in the portfast mode
Link type is point-to-point by default
Bpdu guard is enabled by default
BPDU: sent 1099568, received 0
Вот здоровый аксессный порт. Если соединить его с fa4/11, то с вероятностью 99,999% fa4/10 уйдет в blocking, сразу после получения BPDU, и пользователи ничего не заметят.
Еще раз — should only be enabled on ports connected to a single host. А сдуру можно много чего сломать…
Если человек полагается на «авось», т.е. надеется на то, что никто не соединит соседние порты патч-кордом, то ему вообще нечего делать в IT. Необходимо заранее предусмотреть любые возможные сценарии, ведущие к аварии, и предпринять меры по недопущению как можно большего числа этих аварий. И всегда исходить из того, что пользователь — идиот; вспышки на солнце происходят каждый день; глюк в софте на сетевом железе случается раз в два дня и т.д.
Вы же явно сторонник подхода «если система падает от чиха, то надо запретить чихать, а не устранить источник влияния чиха на стабильность». Так не бывает.
> Необходимо заранее предусмотреть любые возможные сценарии, ведущие к аварии,
> и? предпринять меры по недопущению как можно большего числа этих аварий.
Надо понимать, в комплекс мер по предотвращению у вас входит игнорирование предупреждений вендора о возможности образования петель при тех телодвижениях что вы совершаете?
> и? предпринять меры по недопущению как можно большего числа этих аварий.
Надо понимать, в комплекс мер по предотвращению у вас входит игнорирование предупреждений вендора о возможности образования петель при тех телодвижениях что вы совершаете?
А есть альтернативы? Вы сможете, к примеру, обеспечить работу заливки по PXE без portfast? Нет? Значит, исходим из того, что portfast — данность, от которой следует отталкиваться. Но если пользователь соединит патч-кордом две розетки и сегмент ляжет минут на 10, то виноват будет не пользователь, а сетевик. И даже заклинание «spanning-tree portfast bpduguard default» делу не поможет.
Еще раз. В документации по portfast'у где-то пишется, что после получения BPDU порт моментально переходит в blocking, а затем проходит через нормальный процесс STP. И кольцо должно возникнуть максимум на 2 секунды, что называется не «катастрофа», а «инцидент, который скорее всего останется незамеченным». Я же говорю, что на практике все может быть куда хуже. И мало кто об этом знает. В курсе BCMSN (который Вы явно пропустили, судя по «portfast не рассылает BPDU» :) ) про такой исход дела ни слова не было.
Еще раз. В документации по portfast'у где-то пишется, что после получения BPDU порт моментально переходит в blocking, а затем проходит через нормальный процесс STP. И кольцо должно возникнуть максимум на 2 секунды, что называется не «катастрофа», а «инцидент, который скорее всего останется незамеченным». Я же говорю, что на практике все может быть куда хуже. И мало кто об этом знает. В курсе BCMSN (который Вы явно пропустили, судя по «portfast не рассылает BPDU» :) ) про такой исход дела ни слова не было.
> А есть альтернативы? Вы сможете, к примеру, обеспечить работу заливки по PXE без portfast? Нет?
В условиях взаимоисключающих параграфов (portast на потенциально петлеопасных портах+ доступ идиотов к этим портам) вопрос несколько выходит за рамки spanning tree. Более надежным решением тут видится создание топологии беспетельной от природы с использованием Vlan per port например или Private VLAN.
Еще как ненадежный вариант — portfast trunk: When you enable PortFast between two switches, the system will verify there are no loops in the network before bringing the blocking trunk to a forwarding state. — www.cisco.com/en/US/docs/switches/lan/catalyst4000/7.4/configuration/guide/stp_enha.html#wp1019873 — возможно, на некоторых платформах оно действительно will verify there are no loops in the network before
> В документации по portfast'у где-то пишется, что после получения BPDU порт моментально переходит в blocking, а затем проходит через нормальный процесс STP. И кольцо должно возникнуть максимум на 2 секунды
Все правильно. При условии что продавленный арп-штормом control-plane с другой стороны будет в состоянии отправить этот BPDU например. И что этот BPDU не дропнется на перегруженном порту еще до того как он дойдет до процессора. Нигде не написано что максимальное время броадкаст-шторма при включенном portfast на портах и запетлявшей топологии = 2с. Зачем же это додумывать?
У каждой технологии есть границы применимости, соответственно их нужно либо не нарушать, либо не использовать технологию. А если уже странного хочется, то хотябы понимать где костыли стоят.
В условиях взаимоисключающих параграфов (portast на потенциально петлеопасных портах+ доступ идиотов к этим портам) вопрос несколько выходит за рамки spanning tree. Более надежным решением тут видится создание топологии беспетельной от природы с использованием Vlan per port например или Private VLAN.
Еще как ненадежный вариант — portfast trunk: When you enable PortFast between two switches, the system will verify there are no loops in the network before bringing the blocking trunk to a forwarding state. — www.cisco.com/en/US/docs/switches/lan/catalyst4000/7.4/configuration/guide/stp_enha.html#wp1019873 — возможно, на некоторых платформах оно действительно will verify there are no loops in the network before
> В документации по portfast'у где-то пишется, что после получения BPDU порт моментально переходит в blocking, а затем проходит через нормальный процесс STP. И кольцо должно возникнуть максимум на 2 секунды
Все правильно. При условии что продавленный арп-штормом control-plane с другой стороны будет в состоянии отправить этот BPDU например. И что этот BPDU не дропнется на перегруженном порту еще до того как он дойдет до процессора. Нигде не написано что максимальное время броадкаст-шторма при включенном portfast на портах и запетлявшей топологии = 2с. Зачем же это додумывать?
У каждой технологии есть границы применимости, соответственно их нужно либо не нарушать, либо не использовать технологию. А если уже странного хочется, то хотябы понимать где костыли стоят.
Более надежным решением тут видится создание топологии беспетельной от природы с использованием Vlan per port например или Private VLAN.
На 4500-м каталисте с 300 портами, с текущей конфигурацией по 48 портов на VLAN, по VLANу на порт? Издеваетесь? Большего бреда в жизни не слышал. Мы вроде как о корпоративной сети говорим, а не о провайдере. И думаю, понятно, почему и private vlan идет лесом по определению.
Еще как ненадежный вариант — portfast trunk
Еще одна глупость. Portfast trunk — тот же обычный portfast, предназначенный для подключения транком конечных устройств, не знающих про STP и неспособных создать петлю. Например, гипервизора. Или роутера с сабинтерфейсами. Но и у гипервизора может поехать крыша, и если он вдруг объединит в бридж оба порта — будет network meltdown по моему сценарию. Где-то про такое писали, у кого-то такое было.
При условии что продавленный арп-штормом control-plane с другой стороны будет в состоянии отправить этот BPDU например.
А вот про это в доках не говорится ни явно, ни намеками. И не каждый догадается, что на обработку BPDU может и не хватить ресурсов.
И что этот BPDU не дропнется на перегруженном порту еще до того как он дойдет до процессора.
Дропнется в направлении «in» на перегруженном порту? Любопытно… А на отправку у него и так безусловный приоритет. Иначе типичный congestion обернулся бы кошмарным расколбасом по всей сети, с постоянными перестроениями топологии.
Нигде не написано что максимальное время броадкаст-шторма при включенном portfast на портах и запетлявшей топологии = 2с. Зачем же это додумывать?
Написано, что порт при получении BPDU проходит через нормальный процесс STP. «Максимум 2 секунды» подразумевается. Не будут же они как для идиотов все разжевывать.
У каждой технологии есть границы применимости, соответственно их нужно либо не нарушать, либо не использовать технологию.
Вы предложили две совершенно бредовые альтернативы.
И уж конечно перед рассмотрением других технологий следует хорошенько изучить первоначальную ;) Например, поставить везде storm-control broadcast level 1 — и сеть при шторме не упадет, будут лишь маленькие глючки с полагающимися на броадкаст сервисами (ARP, DHCP), да и то вряд ли — ресурсы свитча не будут исчерпаны, и он спокойно положит закольцованные порты.
«Не нарушать»? Это никуда не годится. Надо сделать так, чтобы и при кратковременном нарушении ничего плохого не происходило. А для этого для начала надо хорошо знать матчасть.
Вы ведь даже не знали, что portfast'овый порт рассылает BPDU :)
И не вздумайте на собеседовании говорить «а давайте каждому по VLANу создадим»…
На 4500-м каталисте с 300 портами, с текущей конфигурацией по 48 портов на VLAN, по VLANу на порт? Издеваетесь? Большего бреда в жизни не слышал. Мы вроде как о корпоративной сети говорим, а не о провайдере. И думаю, понятно, почему и private vlan идет лесом по определению.
Еще как ненадежный вариант — portfast trunk
Еще одна глупость. Portfast trunk — тот же обычный portfast, предназначенный для подключения транком конечных устройств, не знающих про STP и неспособных создать петлю. Например, гипервизора. Или роутера с сабинтерфейсами. Но и у гипервизора может поехать крыша, и если он вдруг объединит в бридж оба порта — будет network meltdown по моему сценарию. Где-то про такое писали, у кого-то такое было.
При условии что продавленный арп-штормом control-plane с другой стороны будет в состоянии отправить этот BPDU например.
А вот про это в доках не говорится ни явно, ни намеками. И не каждый догадается, что на обработку BPDU может и не хватить ресурсов.
И что этот BPDU не дропнется на перегруженном порту еще до того как он дойдет до процессора.
Дропнется в направлении «in» на перегруженном порту? Любопытно… А на отправку у него и так безусловный приоритет. Иначе типичный congestion обернулся бы кошмарным расколбасом по всей сети, с постоянными перестроениями топологии.
Нигде не написано что максимальное время броадкаст-шторма при включенном portfast на портах и запетлявшей топологии = 2с. Зачем же это додумывать?
Написано, что порт при получении BPDU проходит через нормальный процесс STP. «Максимум 2 секунды» подразумевается. Не будут же они как для идиотов все разжевывать.
У каждой технологии есть границы применимости, соответственно их нужно либо не нарушать, либо не использовать технологию.
Вы предложили две совершенно бредовые альтернативы.
И уж конечно перед рассмотрением других технологий следует хорошенько изучить первоначальную ;) Например, поставить везде storm-control broadcast level 1 — и сеть при шторме не упадет, будут лишь маленькие глючки с полагающимися на броадкаст сервисами (ARP, DHCP), да и то вряд ли — ресурсы свитча не будут исчерпаны, и он спокойно положит закольцованные порты.
«Не нарушать»? Это никуда не годится. Надо сделать так, чтобы и при кратковременном нарушении ничего плохого не происходило. А для этого для начала надо хорошо знать матчасть.
Вы ведь даже не знали, что portfast'овый порт рассылает BPDU :)
И не вздумайте на собеседовании говорить «а давайте каждому по VLANу создадим»…
Portfast выполняет ещё одну важную функцию, кроме быстрого up'а порта — он уменьшает количество сообщений topology change, которые приводят к стиранию таблиц MAC-адресов во всём коммутируемом сегменте, в результате чего следует флуд unknow unicast. Т.е. при каждом включении/выключении порта конечным пользователем, вы получаете TCN и последующую очистку mac-tables на всех свичах в домене STP/RSTP. Защита от дурака — это BPDU Guard для STP. В RSTP защита встроенная, при получении BPDU на Edge Port он автоматически перестают рассматриваться, как Edge Port и попадает под обычные действия алгоритма RSTP.
Фу, некропостер!
На самом деле в указанном мной выше контексте особой разницы между BPDU guard и нормальным механизмом STP нет. В обоих случаях при получении BPDU порт будет заблокирован, так как перестанет быть portfast. В одном из них он имеет шанс скоро разблокироваться, если договорится с соседом, в другом останется заблокированным навеки или до истечения recovery таймера.
Защита от дурака — это BPDU Guard для STP
На самом деле в указанном мной выше контексте особой разницы между BPDU guard и нормальным механизмом STP нет. В обоих случаях при получении BPDU порт будет заблокирован, так как перестанет быть portfast. В одном из них он имеет шанс скоро разблокироваться, если договорится с соседом, в другом останется заблокированным навеки или до истечения recovery таймера.
Ну, не так уж игнорируется, по крайней мере в доках (даже на русском)
img.nag.ru/projects/setup/b85/e0b321501dd4f33283adebd69b4fa1db.pdf
В данном примере устройство А является мостом, порт p1 которого уже выполняет пересылку. Для порта p2 включена функция PortFast. Устройство B является концентратором. После подключения второго кабеля к A порт p2 переходит в режим пересылки и образует петлю между p1 и p2. Данная петля разрывается как только p1 или p2 получает BPDU, которое переводит один из этих двух портов в режим блокировки. Однако с таким типом временных петель существует проблема. Если трафик петли слишком интенсивный, у моста может возникнуть проблема успешной передачи BPDU, которое приведет к разрыву петли. Это может привести к значительной задержке сходимости или в крайних случаях остановить работу сети.
img.nag.ru/projects/setup/b85/e0b321501dd4f33283adebd69b4fa1db.pdf
В данном примере устройство А является мостом, порт p1 которого уже выполняет пересылку. Для порта p2 включена функция PortFast. Устройство B является концентратором. После подключения второго кабеля к A порт p2 переходит в режим пересылки и образует петлю между p1 и p2. Данная петля разрывается как только p1 или p2 получает BPDU, которое переводит один из этих двух портов в режим блокировки. Однако с таким типом временных петель существует проблема. Если трафик петли слишком интенсивный, у моста может возникнуть проблема успешной передачи BPDU, которое приведет к разрыву петли. Это может привести к значительной задержке сходимости или в крайних случаях остановить работу сети.
Отличный цикл статей. Большое спасибо!
Анимация хорошая, можно начальству показывать.
В тексте приведены порты fa0/1, fa0/24, на изображениях fe0/1, fe0/24. Я что-то подзабыл с прошлых статей, или опечатка?
Отличная статья, нравится оформление и доступность информации.
Дичайше буду рекомендовать весь цикл ваших статей, тем кто готовиться к CCNA.
Жаль, что я сдавал экзамен раньше чем вы начали это делать — думаю срок самостоятельного обучения сильно бы сократился.
Успехов!
Жаль, что я сдавал экзамен раньше чем вы начали это делать — думаю срок самостоятельного обучения сильно бы сократился.
Успехов!
Спасибо. Я очень надеюсь, что мы ещё затронем интересные вам темы: динамическая маршрутизация, BGP, MPLS, ну и подкаст, конечно.
Спасибо. Но рекомендовать наш цикл я бы стал только в качестве дополнительного материала к официальному курсу. Ну и ничто не заменит Джереми, конечно, если уж говорить о дополнениях :)
UFO just landed and posted this here
Eucariot, у тебя второй аккаунт, что ли?
Для обмена информацией между собой свичи используют специальные пакеты
всё такие пакеты? не кадры?
А как будет STP блокировать порт, если
к cisco подключили 2 ноутбука и «дешёвый» свитч, в котором сделали петлю. 1 ноутбук сможет работать со вторым или нет? Ведь у «дешёвого» свитча нет BPDU, как cisco отключит порт?
к cisco подключили 2 ноутбука и «дешёвый» свитч, в котором сделали петлю. 1 ноутбук сможет работать со вторым или нет? Ведь у «дешёвого» свитча нет BPDU, как cisco отключит порт?
int range fast 0/1 — 24
storm-control broadcast level 80.00
storm-control multicast level 80.00
storm-control unicast level 80.00
storm-control action shutdown
Подробнее тут: xakep.ru/2013/08/23/safe-among-perimetr
storm-control broadcast level 80.00
storm-control multicast level 80.00
storm-control unicast level 80.00
storm-control action shutdown
Подробнее тут: xakep.ru/2013/08/23/safe-among-perimetr
Sign up to leave a comment.
Сети для самых маленьких. Часть четвертая. STP