По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перед тем как начать: почитайте про перераспределение между плоскостями управления в сетях.
Сетевые инженеры обычно думают, что плоскость управления выполняет самые разные задачи, от вычисления кратчайшего пути через сеть до распределения политики, используемой для пересылки пакетов. Однако идея кратчайшего пути проникает в концепцию оптимального пути. Точно так же идея политики также проникает в концепцию оптимизации сетевых ресурсов. Хотя важны и политика, и кратчайший путь, ни один из них не лежит в основе того, что делает плоскость управления. Задача плоскости управления - сначала найти набор путей без петель через сеть. Оптимизация - хорошее дополнение, но оптимизация может быть "сделана" только в контексте поиска набора путей без петель.
Таким образом, в этом разделе будет дан ответ на вопрос: как плоскость управления вычисляет пути без петель через сеть?
Этот цикл статей начнется с изучения взаимосвязи между кратчайшим или наименьшим метрическим путем и безцикловыми путями. Следующая рассматриваемая тема - свободные от циклов альтернативные пути (LFA), которые не являются лучшими путями, но все же свободны от циклов. Такие пути полезны при проектировании плоскостей управления, которые быстро переключаются с наилучшего пути на альтернативный путь без петель в случае сбоев или изменений в топологии сети. Затем обсуждаются два конкретных механизма, используемых для поиска набора безцикловых путей.
Какой путь свободен от петель?
Связь между кратчайшим путем, обычно в терминах метрик, и свободными от циклов путями довольно проста: кратчайший путь всегда свободен от циклов. Причина этой связи может быть выражена наиболее просто в терминах геометрии (или, более конкретно, теории графов, которая является специализированной областью изучения в рамках дискретной математики). Рисунок 1 используется для объяснения этого.
Какие есть пути из A, B, C и D к месту назначения?
Из A: [B, H]; [C, E, H]; [D, F, G, H]
Из B: [H]; [A, C, E, H]; [A, D, F, G, H]
Из D: [F, G, H]; [A, C, E, H]; [A, B, H]
Если каждое устройство в сети должно выбирать путь, который оно будет использовать к месту назначения независимо (без привязки на путь, выбранный любым другим устройством), можно сформировать постоянные петли. Например, A может выбрать путь [D, F, G, H], а D может выбрать путь [A, C, E, H]. Затем устройство A будет перенаправлять трафик к пункту назначения в D, а D затем перенаправит трафик к пункту назначения в A. Должно быть какое-то правило, отличное от выбора пути, реализованного алгоритмом, используемым для вычисления пути на каждом устройстве, например, выбрать самый короткий (или самый дешевый) путь. Но почему выбор кратчайшего (или самого дешевого) пути предотвращает возникновение петли? Рисунок 2 иллюстрирует это.
На рисунке 2 предполагается, что A выбирает путь [D, F, G, H] к месту назначения, а D выбирает путь через A к месту назначения. Чего D не может знать, поскольку он вычисляет путь к месту назначения, не зная, что вычислил A, так это того, что A использует путь через D сам для достижения места назначения. Как может плоскость управления избежать такого цикла? Обратите внимание на то, что стоимость пути вдоль цикла всегда должна включать стоимость цикла, а также элемент пути без петель. В этом случае путь через A с точки зрения D должен включать стоимость от D до места назначения. Следовательно, стоимость через A, с точки зрения D, всегда будет больше, чем наименьшая доступная стоимость из D. Это приводит к следующему наблюдению:
Путь с наименьшей стоимостью (или кратчайший) не может содержать путь, который проходит через вычислительный узел или, скорее, кратчайший путь всегда свободен от петель.
В этом наблюдении есть два важных момента.
Во-первых, это наблюдение не говорит о том, что пути с более высокой стоимостью являются определенно петлями, а только о том, что путь с наименьшей стоимостью не должен быть петлей. Можно расширить правило, чтобы обнаружить более широкий набор путей без петель, помимо пути с наименьшей стоимостью- они называются альтернативами без петель (Loop-Free Alternates).
Во-вторых, это наблюдение справедливо, только если каждый узел в сети имеет одинаковое представление о топологии сети. Узлы могут иметь разные представления о топологии сети по ряду причин, например:
Топология сети изменилась, и все узлы еще не были уведомлены об изменении; отсюда и микропетли.
Некоторая информация о топологии сети была удалена из базы данных топологии путем суммирования или агрегирования.
Метрики настроены так, что путь с наименьшей стоимостью несовместим с разных точек зрения.
Плоскости управления, используемые в реальных сетях, тщательно продуманы, чтобы либо обойти, либо минимизировать влияние различных устройств, имеющих разные представления о топологии сети, что потенциально может привести к зацикливанию пути. Например:
Плоскости управления тщательно настраиваются, чтобы минимизировать разницу во времени между изучением изменения топологии и изменением пересылки (или отбрасывать трафик во время изменений топологии, а не пересылать его).
При обобщении топологии или агрегировании достижимости необходимо позаботиться о сохранении информации о затратах.
"Лучшие общепринятые практики" проектирования сети поощряют использование симметричных метрик, а многие реализации затрудняют или делают невозможным настройку каналов с действительно опасными показателями, такими как нулевая стоимость канала.
Часто требуется много работы, чтобы найти, обойти или предотвратить непреднамеренное нарушение правила кратчайшего пути в реальных протоколах плоскости управления.
Почему бы не использовать список узлов?
На этом этапе должен возникнуть очевидный вопрос: почему бы просто не использовать список узлов для поиска маршрутов без петель? Например, на рисунке 1, если A вычисляет путь через D, может ли D каким-то образом получить путь, вычисленный A, обнаружить, что сам D находится на пути, и, следовательно, не использовать путь через A?
Первая проблема с этим механизмом заключается в процессе обнаружения. Как D должен узнать о пути, выбранном A, и A узнать о пути, выбранном D, не вызывая состояния гонки? Два устройства могут выбрать друг друга в качестве следующего перехода к пункту назначения в один и тот же момент, а затем информировать друг друга в один и тот же момент, в результате чего оба одновременно выбирают другой путь. Результатом может быть либо стабильный набор путей без петель, когда два устройства циклически выбирают друг друга и не имеют пути к месту назначения, либо состояние насыщения, при котором нет пути к месту назначения.
Вторая проблема с этим механизмом - резюмирование - преднамеренное удаление информации о топологии сети для уменьшения количества состояний, переносимых на уровне управления. Плоскость управления будет иметь только метрики, с которыми можно работать, везде, где обобщается топология. Следовательно, лучше использовать правило, основанное на метриках или стоимости, а не на наборе узлов, через которые проходит путь.
Обратите внимание, что обе эти проблемы решаемы. На самом деле существуют алгоритмы вектора пути, которые полагаются на список узлов для вычисления путей без петель через сеть. Хотя эти системы широко распространены, они часто считаются слишком сложными для развертывания во многих ситуациях, связанных с проектированием сетей. Следовательно, широко используются системы на основе метрик или стоимости.
Теперь почитайте материал про построение деревьев в сетях
Интеграция Asterisk и CUCM позволяет по протоколу SIP позволяет объединить несколько телефонных пулов, или, например, использовать Asterisk в роли IVR (голосового меню). Как правильно объединить Asterisk и Cisco Unified Communications Manager через SIP – транк расскажем в статье
Настройка CUCM
Перейдем к настройке Cisco UCM. Для создания нового SIP – транка в раздел Device -> Trunk и нажмите на кнопку Add New. Мы создаем SIP – транк, поэтому, укажите поле Trunk Type и Device Protocol на SIP, как указано на скриншоте ниже:
После указания настроек нажмите Next. В появившемся окне указываем следующие опции:
Device Name - имя для создаваемого SIP – транка. Обязательное поле
Description - описание создаваемого подключения.
Device Pool - выберите девайс пул для SIP – транка. Необходимо, чтобы он совпадал с устройствами, которые будут маршрутизироваться через этот транк. Обязательное поле
Листаем вниз, и находим раздел под названием Inbound Calls и выставляем следующую опцию:
Calling Search Space - имя CSS для SIP - транка. Должно совпадать с маршрутизируемыми устройствами.
Последний шаг настроек находится в разделе SIP Information в пункте Destination, тут настраиваем следующие опции:
Destination Address - Введите IP – адрес вашего Asterisk. Обратите внимание, что по умолчанию порт назначения 5060. Если ваш сервер Asterisk слушает SIP на другом порту, то укажите его в поле Destination Port. Обязательное поле
SIP Trunk Security Profile - профиль безопасности для SIP - транка. Укажите в данном поле Non Secure SIP Trunk Profile. Обязательное поле
Rerouting Calling Search Space - укажите CSS, который указали ранее в разделе настроек Inbound Calls.
Out-Of-Dialog Refer Calling Search Space - аналогично указанному ранее пункту.
SUBSCRIBE Calling Search Space - так же укажите CSS.
SIP Profile - SIP профиль. В данном поле указывается Standard SIP Profile
По окончанию настроек нажмите Save. Маршрутизацию в SIP – транк можно осуществлять с помощью шаблонов, которые настраиваются в настройках Route Pattern.
Настройка со стороны Asterisk
Все настройки SIP – транка на стороне Asterisk будем выполнять с помощью графической оболочки FreePBX 13. Для настройки транка перейдем в раздел Connectivity -> Trunks. Нажмите на + Add Trunk, чтобы создать новый SIP – транк.
Во вкладке General, укажите имя для создаваемого транка. Далее, переходим во вкладку pjsip Settings. Так как в рамках настройки SIP – транка между Asterisk и CUCM мы не используем регистрацию по логину/паролю, то отмечаем следующие опции:
Authentication - выставьте None. Как сказано раньше, мы не используем аутентификацию по логину и паролю.
Registration - выставьте None.
SIP Server - укажите IP – адрес Cisco UCM.
Context - укажите контекст from-internal
Перейдите во вкладку Advanced:
Qualify Frequency - выставьте 60. Интервал в секундах, через который будут отправляться Keep – Alive сообщения для проверки состояния транка.
From Domain - укажите IP – адрес вашего CUCM
Нажмите Submit и затем Apply Config. После этого необходимо настроить маршрутизацию для этого транка. Как это сделать, вы можете прочитать в статье по ссылке ниже:
Маршрутизация вызовов FreePBX
Классический стандарт связующего дерева работает нормально, но в настоящее время для современных сетей он слишком медленный 🐌
В настоящее время мы наблюдаем в наших сетях все больше и больше маршрутизации. Протоколы маршрутизации, такие как OSPF и EIGRP, намного быстрее адаптируются к изменениям в сети, чем spanning-tree. Чтобы не отставать от скорости этих протоколов маршрутизации, была создана еще одна разновидность связующего дерева... (rapid spanning tree) быстрое связующее дерево.
Rapid spanning tree - это не революция spanning tree, а его эволюция. Некоторые вещи были изменены для того, что бы ускорить процесс, но с точки зрения конфигурации - это то же самое, что классический spanning tree . Я называю оригинальное spanning tree "классическим spanning tree".
Азы Rapid spanning tree
Помните состояние портов spanning tree? У нас есть блокирующее, прослушивающее, обучающее и пересылающее состояние порта. Это первое различие между spanning tree и rapid spanning tree. Rapid spanning tree имеет только три состояния портов:
Отбрасывание;
Обучение;
Пересылка.
Вы уже знакомы с состоянием порта в режиме обучения и пересылки, но отбрасывание - это новое состояние порта. В основном он объединяет в себе блокировку и прослушивание состояния порта.
Вот хороший обзор с различными состояниями портов для spanning tree и rapid spanning tree. В таблице отображено состояние портов: активны ли они и узнают ли они MAC-адреса или нет.
Помните ли вы все остальные роли портов, которые есть у spanning tree? Давайте сделаем небольшой обзор, и будет показано отличие от rapid spanning tree.
Коммутатор с лучшим ID моста (priority + MAC -адрес) становится корневым мостом. Другие коммутаторы (non-root) должны найти кратчайший путь стоимости к корневому мосту. Это корневой порт. Здесь нет ничего нового, все это работает аналогично и в rapid spanning tree.
На каждом сегменте может быть только один назначенный порт, иначе мы получим петлю. Порт станет назначенным портом, если он сможет отправить лучший BPDU. Коммутатор А, как корневой мост, всегда будет иметь лучшие порты, поэтому все интерфейсы будут назначены. Интерфейс fa0/16 на коммутаторе B будет назначенным портом в моем примере, потому что он имеет лучший идентификатор моста, чем коммутатор C. Здесь все еще нет ничего нового по сравнению с классическим связующим деревом.
Коммутатор C получает лучшие BPDU на своем интерфейсе fa0/16 от коммутатора B, и таким образом он будет заблокирован. Это альтернативный порт, и это все еще то же самое, что и для rapid spanning tree.
Вот вам новый порт, взгляните на интерфейс fa0/17 коммутатора B. Он называется резервным портом и является новым для rapid spanning tree. Однако вы вряд ли увидите этот порт в производственной сети. Между коммутатором B и коммутатором C был добавлен хаб. Обычно (без промежуточного концентратора) оба fa0/16 и fa0/17 будут назначены портами. Из-за хаба интерфейсы fa0/16 и fa0/17 коммутатора B теперь находятся в одном домене коллизий. Fa0/16 будет выбран в качестве назначенного порта, а fa0/17 станет резервным портом для интерфейса fa0/16. Причина, по которой коммутатор B видит интерфейс fa0/17 в качестве резервного порта, заключается в том, что он получает свои собственные BPDU на интерфейсах fa0/16 и fa0/17 и понимает, что у него есть два соединения с одним и тем же сегментом. Если вы удалите хаб, то fa0/16 и fa0/17 будут назначены портами точно так же, как classic spanning tree.
BPDU отличается для rapid spanning tree. В classic spanning tree поле flags использовало только два бита:
Topology change.;
Topology change acknowledgment.;
Теперь используются все биты поля flags. Роль порта, который создает BPDU, будет добавлена с помощью поля port role, оно имеет следующие параметры:
Unknown;
Alternate / Backup port;
Root port;
Designated port.
Эта BPDU называется BPDUv2. Коммутаторы, работающие со старой версией spanning tree, проигнорируют эту новую версию BPDU. Если вам интересно ... rapid spanning tree и старое spanning tree совместимы! Rapid spanning tree способно работать с коммутаторами, работающими под управлением более старой версии spanning tree.
Что поменялось
BPDU теперь отправляются каждый hello time. Только корневой мост генерирует BPDU в classic spanning tree, и они ретранслировались non-root, если они получали его на свой корневой порт. Rapid spanning tree работает по-разному...все коммутаторы генерируют BPDU каждые две секунды (hello time). Это hello timeпо умолчанию, но вы можете его изменить.
classic spanning tree использует максимального время жизни (20 секунд) для BPDU, прежде чем они будут отброшены. Rapid spanning работает по-другому! BPDU теперь используются в качестве механизма поддержания активности, аналогичного тому, что используют протоколы маршрутизации, такие как OSPF или EIGRP. Если коммутатор пропускает три BPDU от соседнего коммутатора, он будет считать, что подключение к этому коммутатору было потеряно, и он немедленно удалит все MAC-адреса.
Rapid spanning tree будет принимать низшие BPDU. Classic spanning tree игнорирует их. Скорость перехода (время сходимости) является наиболее важной характеристикой rapid spanning tree. Classic spanning tree должно было пройти через состояние прослушивания и обучения, прежде чем оно переведет интерфейс в forwarding состояние, это занимает 30 секунд (таймер по умолчанию). Classic spanning было основано на таймерах.
Rapid spanning не использует таймеры, чтобы решить, может ли интерфейс перейти в forwarding состояние или нет. Для этого он будет использовать переговорный (negotiation) механизм. Чуть позже я покажу вам, как это работает.
Помните ли вы понятие portfast? Если мы включим portfast во время запуска classic spanning tree, оно пропустит состояние прослушивания и обучения и сразу же переведет интерфейс в forwarding состояние. Помимо перевода интерфейса в forwarding состояние, он также не будет генерировать изменения топологии, когда интерфейс переходит в состояние UP или DOWN. Мы все еще используем portfast для rapid spanning tree, но теперь он называется пограничным портом (edge port).
Rapid spanning tree может только очень быстро переводить интерфейсы в forwarding состояние на edge ports (portfast) или интерфейсы типа point-to-point. Он будет смотреть на link type, и есть только два ink types:
Point-to-point (full duplex);
Shared (half duplex).
Обычно мы используем коммутаторы, и все наши интерфейсы настроены как full duplex, rapid spanning tree видит эти интерфейсы как point-to-point. Если мы введем концентратор в нашу сеть, то у нас будет half duplex, который рассматривается как shared interface к rapid spanning-tree.
Позвольте мне описать механизм быстрой синхронизации spanning tree, используя рисунок выше. Коммутатор А сверху - это корневой мост. Коммутатор B, C и D- некорневые мосты (non-root).
Как только появится связь между коммутатором А и коммутатором B, их интерфейсы будут находиться в режиме блокировки. Коммутатор B получит BPDU от коммутатора A, и теперь будет происходить согласование, называемое синхронизацией.
После того, как коммутатор B получил BPDU от корневого моста, он немедленно блокирует все свои порты, не обозначенные в списке non-edge. Non-edge порты - это интерфейсы для подключения к другим коммутаторам, пока edge порты- интерфейсы, настроены как portfast. Как только коммутатор B блокирует свои non-edge порты, связь между коммутатором A и коммутатором B переходит в forwarding состояние.
Коммутатор B также выполнит операцию синхронизации как с коммутатором C, так и с коммутатором D, чтобы они могли быстро перейти в forwarding состояние.
Главное, что следует усвоить здесь, заключается в том, что rapid spanning tree использует этот механизм синхронизации вместо механизма "таймера", который использует classic spanning tree (прослушивание → обучение → forwarding).
Давайте увеличим масштаб механизма синхронизации rapid spanning tree, подробно рассмотрев коммутатор A и коммутатор B. Сначала интерфейсы будут заблокированы до тех пор, пока они не получат BPDU друг от друга. В этот момент коммутатор B поймет, что коммутатор A является корневым мостом, потому что он имеет лучшую информацию BPDU. Механизм синхронизации начнется, потому что коммутатор А установит proposal bit в поле flag BPDU.
Коммутатор B получает предложение от коммутатора A и понимает, что он должен что-то сделать. Он заблокирует все свои non-edge интерфейсы и запустит синхронизацию в направлении коммутатора C и коммутатора D.
Как только коммутатор B перевед свои интерфейсы в режим синхронизации, это позволит коммутатору А узнать об этом, отправив соответствующее соглашение.
Это соглашение является копией proposal BPDU, где proposal bit, был switched off, а agreement bit - switched on. Интерфейс fa0/14 на коммутаторе B теперь перейдет в режим forwarding.
Как только коммутатор A получит соглашение от коммутатора B, он немедленно переведет свой интерфейс fa0/14 в режим пересылки. А как насчет интерфейса fa0 / 16 и fa0 / 19 на коммутаторе B?
Точно такой же механизм синхронизации будет иметь место и сейчас на этих интерфейсах. Коммутатор B направит предложение по своим интерфейсам fa0/16 и fa0/19 в сторону коммутатора C и коммутатора D.
Коммутатор C и коммутатор D не имеют никаких других интерфейсов, поэтому они отправят соглашение обратно на коммутатор B.
Коммутатор B переведет свои интерфейсы fa0/16 и fa0/19 в режим forwarding, и на этом мы закончим. Этот механизм синхронизации - всего лишь пара сообщений, летающих туда-сюда, и очень быстро, это намного быстрее, чем механизм на основе таймера classic spanning tree!
Что еще нового в rapid spanning tree?
Есть еще три вещи:
UplinkFast;
Механизм изменения топологии;
Совместимость с классическим связующим деревом.
Когда вы настраиваете classic spanning tree, вы должны включить UplinkFast самостоятельно. Rapid spanning tree использует UpLinkFast по умолчанию, вам не нужно настраивать его самостоятельно. Когда коммутатор теряет свой корневой порт, он немедленно переводит свой альтернативный порт в forwarding.
Разница заключается в том, что classic spanning tree нуждалось в multicast кадрах для обновления таблиц MAC-адресов всех коммутаторов.
Нам это больше не нужно, потому что механизм изменения топологии для rapid spanning tree отличается. Так что же изменилось в механизме изменения топологии?
С classic spanning tree сбой связи вызвал бы изменение топологии. При использовании rapid spanning tree сбой связи не влияет на изменение топологии. Только non-edge интерфейсы (ведущие к другим коммутаторам), которые переходят в forwarding состояние, рассматриваются как изменение топологии. Как только коммутатор обнаружит изменение топологии это произойдет:
Он начнет изменение топологии при значении таймера, которое в два раза превышает hello time. Это будет сделано для всех назначенных non-edge и корневых портов.;
Он будет очищать MAC-адреса, которые изучаются на этих портах.;
До тех пор, пока происходит изменение топологии, во время активности таймера, он будет устанавливать бит изменения топологии в BPDU, которые отправляются из этих портов. BPDU также будет отправлен из своего корневого порта.;
Когда соседний коммутатор получит этот BPDU с установленным битом изменения топологии, произойдет следующее:
Он очистит все свои MAC-адреса на всех интерфейсах, кроме того, на котором он получил BPDU с включенным изменением топологии.;
Он запустит изменение топологии во время самого таймера и отправит BPDU на все назначенные порты и корневой порт, установив бит изменения топологии.;
Вместо того, чтобы отправлять изменения топологии вплоть до корневого моста, как это делает classic spanning tree, изменение топологии теперь быстро распространяется по всей сети.
И последнее, но не менее важное, давайте поговорим о совместимости. Rapid spanning tree и classic spanning tree совместимы. Однако, когда коммутатор, на котором работает Rapid spanning tree, связывается с коммутатором, на котором работает classic spanning tree, все функции скоростной передачи данных не будут работать!
В приведенном выше примере у меня есть три коммутатора. Между коммутатором A и коммутатором B мы запустим rapid spanning tree. Между коммутатором B и коммутатором C мы вернемся к classic spanning tree.