В 2009-2010 наша сеть закончила переход на управляемое оборудование на доступе, но все еще имела большие по протяженности "гирлянды". В район приходила оптика, откуда в разные стороны тянулись цепочки коммутаторов. Иногда некоторые такие цепочки подходили достаточно близко к другим и тогда организовывались кольца. Кольца управлялись протоколом RSTP, который размыкал их в нужном месте и определял оптимальный путь к центру сети. Тем самым достигалась относительная отказоустойчивость работы - при обесточивании одного узла кольцо автоматически разрывалось, а протокол RSTP находил новое направление к центру. Сейчас считается, что "кольца на доступе - это диагноз", но тогда были другие времена. :) Несмотря на то, что кольца были организованы не везде, STP (RSTP) был настроен на всех коммутаторах, поскольку его можно было использовать с пользой совсем не по назначению.
В те времена большинство магистральных линий были медными. Делились они, в свою очередь, на два типа: "пэха" и "внешка", т.е. с использованием армейского кабеля П-296 или витой пары в жесткой оплетке (кажется, FTP), соответственно. Каждый тип линии имел свои проблемы. Кабель П-296 нуждался в дополнительной разделке, после чего он скручивался с небольшим хвостиком "внешки", который уже обжимался и затем вставлялся в коммутатор. Места "скруток" иногда окислялись, что приводило к ухудшению качества линии. Плюс ко всему, на такой линии можно было поднять только 100Мбитный линк, т.к. в кабеле П-296 всего 4 жилы. Линия же, построенная исключительно на "внешке", позволяла поднимать 1Гбитные линки, не требовала разделки и дополнительных "скруток", но ее легче было повредить и она была намного чувствительнее к статическому электричеству и прочим помехам. Вообще, по-хорошему, медные линии не должны висеть в воздухе, да и на крышах их присутствие нежелательно. Но тогда все строили как умели, а зачастую и вовсе пользовались наследием начала 2000-х.
Вернемся к STP. Точный принцип работы я не помню, но суть такова: через короткие интервалы времени с определенных администратором портов рассылаются BPDU-фреймы, содержащие информацию о топологии сети. На основе этой информации коммутаторы определяют кратчайший путь к корню - ядру сети. Если однажды появляются новые фреймы или пропадают старые - топология перестраивается. Существуют специальные указания на перестроение - Topology Change Notification. Кстати, на портах клиентов STP обычно выключают, чтобы избежать как лишних перестроений, так и несанкционированного изменения STP-дерева.
Ну и, наконец, суть. Помехи, воздействовавшие на медные линии, либо иные повреждения (окисления "скруток") могли приводить к некоторой деградации качества связи, которое не обнаруживалось явно, но мешало работе STP. Иными словами, абоненты еще не жаловались, но BPDU-фреймы уже начинали теряться, что приводило к перестроению дерева, а коммутатор оставлял в системном логе сообщение New Root Selected, где корнем становится он сам. Как правило, уже через несколько секунд топология восстанавливалась, но такие сообщения указывали на наличие проблем где то за uplink'ом данного коммутатора. Системы мониторинга, которая анализировала бы ошибки на магистральных портах, тогда еще не было (говоря по правде, ее и сейчас нет :) ), а вот система сбора логов с коммутаторов уже работала. Изучая сообщения о выборе new root можно было найти проблемный участок и предпринять меры до того, как деградация качества будет замечена абонентами.
Вот такая вот история. :) Сейчас это уже не актуально - все магистрали переведены на оптоволокно, разобраны почти все гирлянды, STP не нужен ни в каком виде, но 5 лет назад все было не так. :)
В те времена большинство магистральных линий были медными. Делились они, в свою очередь, на два типа: "пэха" и "внешка", т.е. с использованием армейского кабеля П-296 или витой пары в жесткой оплетке (кажется, FTP), соответственно. Каждый тип линии имел свои проблемы. Кабель П-296 нуждался в дополнительной разделке, после чего он скручивался с небольшим хвостиком "внешки", который уже обжимался и затем вставлялся в коммутатор. Места "скруток" иногда окислялись, что приводило к ухудшению качества линии. Плюс ко всему, на такой линии можно было поднять только 100Мбитный линк, т.к. в кабеле П-296 всего 4 жилы. Линия же, построенная исключительно на "внешке", позволяла поднимать 1Гбитные линки, не требовала разделки и дополнительных "скруток", но ее легче было повредить и она была намного чувствительнее к статическому электричеству и прочим помехам. Вообще, по-хорошему, медные линии не должны висеть в воздухе, да и на крышах их присутствие нежелательно. Но тогда все строили как умели, а зачастую и вовсе пользовались наследием начала 2000-х.
Вернемся к STP. Точный принцип работы я не помню, но суть такова: через короткие интервалы времени с определенных администратором портов рассылаются BPDU-фреймы, содержащие информацию о топологии сети. На основе этой информации коммутаторы определяют кратчайший путь к корню - ядру сети. Если однажды появляются новые фреймы или пропадают старые - топология перестраивается. Существуют специальные указания на перестроение - Topology Change Notification. Кстати, на портах клиентов STP обычно выключают, чтобы избежать как лишних перестроений, так и несанкционированного изменения STP-дерева.
Ну и, наконец, суть. Помехи, воздействовавшие на медные линии, либо иные повреждения (окисления "скруток") могли приводить к некоторой деградации качества связи, которое не обнаруживалось явно, но мешало работе STP. Иными словами, абоненты еще не жаловались, но BPDU-фреймы уже начинали теряться, что приводило к перестроению дерева, а коммутатор оставлял в системном логе сообщение New Root Selected, где корнем становится он сам. Как правило, уже через несколько секунд топология восстанавливалась, но такие сообщения указывали на наличие проблем где то за uplink'ом данного коммутатора. Системы мониторинга, которая анализировала бы ошибки на магистральных портах, тогда еще не было (говоря по правде, ее и сейчас нет :) ), а вот система сбора логов с коммутаторов уже работала. Изучая сообщения о выборе new root можно было найти проблемный участок и предпринять меры до того, как деградация качества будет замечена абонентами.
Вот такая вот история. :) Сейчас это уже не актуально - все магистрали переведены на оптоволокно, разобраны почти все гирлянды, STP не нужен ни в каком виде, но 5 лет назад все было не так. :)
Можете поподробнее описать текущую топологию подключения коммутаторов доступа к агрегирующему узлу? Как и по каким причинам пришлось отказаться от кольца? Или лучше написать отдельную статью
ОтветитьУдалитьНа статью материала, пожалуй, не хватит, но общее представление дать постараюсь.
ОтветитьУдалитьЭтап 1:
До 2011 года в сети был ярко выраженный центр в виде Catalyst 6500 из которого выходили лучики звезды к агрегаторам DGS-3100-24TG, уже откуда, в свою очередь, произрастали гирлянды коммутаторов DES-3028. Многие магистрали линии были медными.
Этап 2:
В 2011 году произошло слияние компаний, общая территория покрытия резко увеличилась, а "меньшая" сеть унаследовала подход "большей". В сети получилось около 30 узлов агрегации на периферии, где каждый узел представлял собой звездочку, а луч мог содержать 3-4 дома. На узлах стояли Foundry FastIron/BigIron и, иногда, Catalyst 3550. Среди коммутаторов значительный теперь процент составляли DES-3200-28. Общая топология стремилась к схеме оптоволокно-на-здание (FTTB).
Этап 3:
В 2012-2014 годах наметился переход к топологии волокно-на-узел (или волокно-на-бокс), цепочки коммутаторов практически пропали. При этом из практики стало понятно, что обслуживать большое количество узлов агрегации неудобно. Некоторые узлы начали объединяться. Образовалось несколько гигантских звезд с одним конечным узлом на каждом луче.
В более крупной сети STP не использовался изначально так как: а) железо, с которого производился переход к D-Link представляло собой зоопарк; б) длинных гирлянд никогда не было и вопрос резервного включения домов остро не стоял. Резервные каналы связи организовывались уже между узлами агрегации и работали исключительно на L3. Такой способ не в пример надежнее и намного удобнее.
Чем не понравился STP (опыт получен в 2009 году):
1. Разорванное кольцо могло внезапно замкнуться, успешно проработав, например, месяц. Причины, по которым это происходило, так и остались загадкой. Была ли это ошибка настройки, программный дефект типа конфликта хеш или аппаратный, вроде сгоревшего порта, теперь уже не понятно. Кольцо тогда вставлялось в ядро, у которого в момент замыкания тоже начинались неприятности.
2. Другое кольцо у нас замыкалось из-за того, что на одном из его коммутаторов было обновлено ПО. Обновление было довольно глобальным (пропущено множество промежуточных версий) и, судя по всему, имело отличия в реализации STP. И пока каждый коммутатор не был обновлен, STP корректно функционировать не захотел.
В общем, мы пришли к выводу, что STP не предсказуем и по прямому назначению его использовать перестали.