Тема охватывает несколько тем, поэтому я бы попытался разбить ее дальше, чтобы предоставить больше информации, а также лучше понять технологию.
Сначала немного предыстории - мы проводим вечеринку по локальной сети с большим количеством участников. Количество подключенных компьютеров варьируется от 200 до 600 (может быть и больше). У нас есть управляемые коммутаторы Netgear FS726T с гигабитными каналами, ведущими к базовому гигабитному коммутатору. Сеть настраивается как минимум за пару часов до прихода людей и используется в течение 24-48 часов. На этих коммутаторах Netgear мы включили 802.1d, чтобы избежать петель, но все осталось с настройками по умолчанию.
У нас есть контроль над следующими настройками STP 802.1d (с их диапазонами):
На порт:
Вот несколько дополнительных вопросов:
Это изменения, которые я рассматривал вместе с причинами, почему - правильно ли я думаю?
Любая информация и частичные ответы приветствуются. Также будет приветствоваться информация о том, где найти дополнительную информацию по этой теме.
Спасибо
максимально увеличить возраст, чтобы максимально избежать перестройки вычислений связующего дерева (поскольку сеть не изменится после ее создания)
Предлагаемые вами оптимизации и изменения будут спорными, если топология сети все равно не изменится. Spanning-tree - это в первую очередь протокол с низким уровнем воздействия. 600 портов / станций - это не так уж и много в большой схеме вещей, учитывая связующее дерево.
Прелесть STP в том, что в подавляющем большинстве случаев он заботится о себе сам - возясь со стандартными, проверенными и проверенными настройками по умолчанию, вы рискуете ухудшить ситуацию для вашего мероприятия - и может повлиять на ваших конечных пользователей для относительно короткое время они используют вашу сеть.
уменьшить стоимость пути на ссылке к базовому коммутатору, чтобы указать предпочтительный путь
увеличить приоритет ссылки на ядро (как указано выше)
Это почти как если бы вы в первую очередь пытались победить цель STP; что, если вам внезапно придется изменить топологию вашей сети (коммутатор или канал выйдет из строя и произойдет событие конвергенции STP?), вы потратите время на изменение конфигурации затрат / приоритетов - что вам не нужно делать, если STP остался в покое. В любом случае настройте коммутатор как корневой BDPU, и вам не придется беспокоиться о ручных затратах пути.
видеть http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml
с этими таймерами связано много вещей, некоторые из вещей, которые вас беспокоят, выглядят как преждевременная оптимизация ...
что вам следует делать:
Вы хотите, чтобы ваш основной коммутатор был корнем связующего дерева. Установите приоритет моста на основном коммутаторе на самое низкое значение. IOS позволяет вам использовать специальный приоритет 'primrary', который устанавливает его на 8192, так что я полагаю, вы могли бы это использовать. Убедитесь, что порты конечных пользователей имеют portfast и bdpuguard или что-то еще, что поддерживает Netgear, чтобы сказать, что «этот порт не должен питать другие коммутаторы»
максимально увеличить время приветствия, чтобы свести к минимуму болтовню (причины, аналогичные приведенным выше)
Я бы этого не трогал, это влияет на все остальное. Я почти уверен, что увеличение времени приветствия увеличивает время, необходимое для обнаружения цикла, а это не то, что вам нужно.
минимизировать задержку пересылки, чтобы начать отправку реальных пакетов как можно быстрее
Это может быть полезно, если кабель отключен, но на самом деле это сэкономит вам не более 30 секунд или около того, что может быть недостаточно, чтобы окупить его.
увеличить стоимость пути на стандартных портах, чтобы избежать перехвата трафика подключенными машинами
В ciscoland для портов конечных пользователей вы должны включить portfast и bdpuguard и все прочие забавные вещи. Порты конечных пользователей не должны участвовать в связующем дереве в первую очередь, поэтому стоимость порта на самом деле не имеет значения.
уменьшить стоимость пути на ссылке к базовому коммутатору, чтобы указать предпочтительный путь
В этом нет необходимости, если вы сделаете ядро корнем связующего дерева.
увеличить приоритет ссылки на ядро (как указано выше)
В этом нет необходимости, если вы сделаете ядро корнем связующего дерева.
Могут ли эти изменения повлиять на производительность сети (как задержку, так и скорость передачи)?
Нет. Единственное, с чем они могут помочь, - это более быстрое восстановление, если кто-то отключит / перезагрузит коммутатор. Я собираюсь предположить, что если это произойдет, любая текущая игра будет прервана, поэтому возвращение ее к сети через 15 секунд вместо 45 не будет иметь большого значения для игроков.
Если у вас нет зацикленной топологии (также известной как избыточные ссылки уровня 2), то связующее дерево на самом деле мало что делает.