Не путайте человека, обычному l2 коммутатору глубоко до лампочки ip адреса, никакие arp таблицы он не смотрит.
Есть такое понятие - unknown unicast. Условия его возникновения несколько специфичны, однако реальны.
Так что "из древних времён 10Base" встречается и сейчас.
Лично я бы там, где не надо получать bpdu-- складывал порт, то бишь bpdu guard.
Слепо этому совету следовать, конечно же, не стоит, надо подумать, а "что будет если", после чего выбрать уже верный вариант.
Представил схему в голове, не уверен, что правильно.
Но в общем случае мjе мнение примерно следующее...
По поводу штормов multicast/unicast.
Тут надо выбирать из того, что вам надо, на самом деле, как бы это странно ни звучало.
И что случится, если внезапно положится порт, что перестанет работать в случае этого.
Но я так понимаю, что разговор идет о так скажем абонентских портах.
В этом случае наверное разницы нет.
Лично я бы выбрал supression с низким значением.
Можно хоть глянуть, что там, что и как починить, в случае чего, подсказать.
По stp:
Лично мое мнение такое -- stp нигде принудительно не отключать (в том смысле, чтоб ну вот прям совсем no spanning-tree vlan ХХХ), петли могут возникнуть где угодно и как угодно.
Не верю я, что ну вот 100% ошибки при коммутации не будет.
Лучше где надо -- развесить bpdu guard/bpdu filter вместе с edge.
При этом надо помнить, что bpdu filter работает в обоих направлениях, а bpdu guard -- в одном.
А так же, что bpdu filter перекрывает bpdu guard.
Посыпаю голову пеплом, я немного ошибся. Если выключать stp на интерфейсе , то чужой bpdu он все же пропускает, но просто сам не обрабатывает его.
Что в общем-то логично, ибо bpdu - просто мультикастовый фрейм.
Вобще было бы интересно глянуть дамп трафика на этот счет.
Так вы бы обозначили проблему, может решение бы подсказали. (да, видел вашу тему на наге)
Если выключить STP на порту -- сам коммутатор bpdu, конечно же, не пошлет bpdu с этого порта.
Однако что будет, если bpdu придет на порт, на котором выключен stp -- честно говоря, не знаю что произойдет с bpdu в случае Huawei. По хорошему -- bpdu дропнется. В этом случае вы не сможете предотвратить образованию петли, коммутатор не узнает, что там петля и будет спокойно продолжать форвардить трафик, даже закольцованный.
В случае edge -- у вас есть возможность включить защиту, при получении bpdu на этом порту хотя бы сложить его, не допустив образования петли.
Ну в принципе можно включить bpdu filter на порту, что будет аналогично выключению stp на этом интерфейсе.
edge позволят придать "стабильности" топологии за счет игнорирования изменения состояния такого порта, понижения времени сходимости, но с возможностью реагирования при получении bpdu.
В случае сервера, рабочей станции -- они таки в stp вообще не должны участвовать, не должны посылать bpdu, не должны влиять на топологию. Так что там рекомендуют правильно)
Абсолютно серьезно.
Вы берете несколько свитчей с разными control-plane, стекируете их, и получаете один такой большой свитч и одним таким control-plane, в котором,конечно же, найдется много интересных багов. (и не говорите, что их нет, баги есть везде). Это только лишь один из примеров. И я не говорю о всяких падениях пропускных способностей и прочих особенностях каждой из реализаций.
Использовать можно только если критичность сервиса стремится к нулю.
Лучше стоящей рядом отдельной железки с таким же функционалом в качестве резерва ничего нет.
В случае l3 даже вариации stp будет во многих случаях надежней и более предсказуем, нежели стек.
И тем более от работающего stp все равно не откажетесь.