Оптимальные параметры производительности для протокола Spanning Tree Protocol (802.1d) для среды LAN (игровой)
Эта тема охватывает несколько тем, поэтому я постараюсь разбить ее дальше, чтобы получить больше информации и лучше понять технологию.
Сначала немного предыстории - мы проводим локальную LAN-вечеринку с большим количеством участников. Количество подключенных компьютеров варьируется от 200 до 600 (может быть больше). У нас есть управляемые коммутаторы Netgear FS726T с гигабитными каналами, ведущими к основному гигабитному коммутатору. Сеть настраивается по крайней мере за пару часов до прихода людей и используется в течение 24-48 часов. На этих коммутаторах Netgear мы включили 802.1d, чтобы избежать петель, но все осталось с настройками по умолчанию.
У нас есть контроль над следующими настройками STP 802.1d (с их диапазонами):
- Приоритет моста (0-65535)
- Мост Макс Возраст (6-20)
- Мост Привет Время (1-10)
- Задержка переадресации моста (4-30)
На порт:
- Стоимость пути (1-65535)
- Приоритет (0-255)
Вот некоторые дополнительные вопросы:
- Как настроить параметры 802.1d для наилучшего соответствия этому сценарию?
- Могут ли эти изменения повлиять на производительность сети (как отставание, так и скорость передачи)?
Это те изменения, которые я рассматривал, а также причины, почему - правильное ли мое мышление?
- максимизируйте возраст, чтобы избежать перестройки вычислений связующего дерева в максимально возможной степени (потому что сеть не изменится, как только она будет установлена)
- увеличить время приветствия, чтобы свести к минимуму болтовню (причины, аналогичные приведенным выше)
- минимизировать задержку пересылки, чтобы как можно быстрее начать отправку реальных пакетов
- увеличить стоимость пути на стандартных портах, чтобы избежать перехвата трафика на подключенных компьютерах
- уменьшите стоимость пути на ссылке к основному коммутатору, чтобы указать предпочтительный путь
- увеличить приоритет ссылки на ядро (как указано выше)
Любая информация и частичные ответы будут оценены. Информация о том, где можно найти дополнительную информацию по этой теме, также будет оценена.
Спасибо
2 ответа
См . 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), тогда связующее дерево на самом деле не делает много.
максимизируйте возраст, чтобы избежать перестройки вычислений связующего дерева в максимально возможной степени (потому что сеть не изменится, как только она будет установлена)
Оптимизации и изменения, которые вы предлагаете, являются спорными, если топология сети все равно не изменится. Spanning-tree - это протокол с низким уровнем воздействия. 600 портов / станций не так уж много в большой схеме вещей с учетом связующего дерева.
Прелесть STP в том, что в подавляющем большинстве случаев он заботится о себе сам, - покоряя стандартные, проверенные и испытанные значения по умолчанию, вы рискуете ухудшить ситуацию для вашего мероприятия - и может повлиять на ваших конечных пользователей для относительно короткое время они используют вашу сеть.
уменьшите стоимость пути на ссылке к основному коммутатору, чтобы указать предпочтительный путь
увеличить приоритет ссылки на ядро (как указано выше)
Это почти как если бы вы пытались победить цель STP в первую очередь; Что если вам внезапно придется изменить топологию вашей сети (коммутатор или канал перестают работать, и возникает событие конвергенции STP?), вы потратите время на переконфигурирование затрат / приоритетов - что вам не нужно делать, если STP остался один. Обязательно настройте коммутатор в качестве корневого BDPU, и вам не нужно будет беспокоиться о стоимости пути вручную.