По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
3CX программная IP-АТС на открытых стандартах с технологиями Унифицированных коммуникаций и интеграцией услуг в режиме реального времени. Это простая в установке, настройке и сопровождении IP-АТС.
/p>
В данной статье мы рассмотрим процесс настройки IP-DECT-базы Gigaset N870 IP PRO для работы с IP-АТС 3CX и последующего подключения IP-DECT-телефонов Gigaset серии PRO.
DECT (Digital Enhanced Cordless Telecommunication) технология беспроводной связи, использующая частоты 1880-1900 МГц с модуляцией GMSK (ВТ = 0,5). Используется в современных радиотелефонах. Пользуется высокой популярностью благодаря простоте развертывания DECT-сетей, широкому спектру предоставляемых пользовательских услуг и высокому качеству связи.
Достоинства DECT
хорошая помехоустойчивость канала связи благодаря цифровой передаче сигнала.
хорошая интеграция с системами корпоративной телефонии
меньшее облучение абонента (по сравнению с мобильными телефонами)
Недостатки DECT
небольшая дальность связи
невысокая скорость передачи данных (по сравнению с Wi-Fi)
Микросотовая SIP DECT система на базе Gigaset N870 IP PRO позволяет развернуть бесшовную масштабируемую микросотовую систему вплоть до 20000 абонентов. О настройке DECT станции для работы с 3CX и пойдет речь в данной статье.
Поддержка данной DECT-базы со стороны 3CX возможна, начиная с версии DECT-базы 2.16.2 и выше.
Шаг 1. Включение DHCP мода (All in One)
Зажмите кнопку базы на 10 секунд, до тех пор, пока не выключатся LED индикаторы.
Нажав на кнопку, выберите роль устройства. В зависимости от цвета и сочетания LED индикаторов, база будет иметь разные роли.
Нажмите кнопку базы. Оба LED индикатора станут синими и база получит роль Интегратор/DECT-менеджера/База с динамическим IP-адресом.
Зажмите кнопку базы на 5 секунд для подтверждения новой роли.
Устройству необходимы 5 минут на перезагрузку и появления в сети как Интегратора/DECT-менеджера/Базы с настройками по умолчанию.
После перезагрузки, LED-светодиоды на базовой станции показывают разными цветами когда изменяется роль.
Шаг 2. Обновление базы до рекомендуемой версии программного обеспечения
Последние поддерживаемые версии программного обеспечения (ПО) можно скачать
здесь (https://teamwork.gigaset.com/gigawiki/pages/viewpage.action?pageId=702251506)
Введите в браузере IP-адрес базы. В роли Интегратора с динамическим IP-адресом, DECT-база получает IP-адрес от DHCP-сервера. Найдите IP-адрес базы на своем DHCP сервере по MAC-адресу базы (указан на обратной стороне устройства). При необходимости обратитесь к вашему системному администраторе. Для подключения рекомендуется использовать веб-браузер Google Chrome или Mozilla Firefox.
Введите логин admin и пароль admin.
При первом подключении необходимо установить новый пароль и выбрать DECT-диапазон. Введите новый пароль, выберите диапазон 1880 1900 МГц для Европы. Затем нажмите на кнопку Set.
Перейдите в Settings , затем перейдите в System -> Firmware.
Нажмите на Browse и выберите файл прошивки, который вы хотите установить.
Нажмите на кнопку Upload и дождитесь завершения загрузки файла на базу.
Нажмите на кнопку Set для начала обновления и загрузки ПО.
Шаг 3. Настройка базы в 3CX.
Запишите MAC адрес базы (указан на обратной стороне устройства).
В 3CX перейдите в Дополнительно -> Устройства FXS/DECT.
Нажмите на Добавить FXS/DECT
Выберите производителя Gigaset. Выберите модель Gigaset N870. Укажите MAC-адрес устройства. Нажмите ОК.
Скопируйте ссылку автонастройки.
Перейдите на вкладку Добавочные номера и выберите номер, который будет назначен на данную базу. Нажмите ОК.
Шаг 4. Настройка базы через Веб-интерфейс.
Введите IP-адрес базы в адресную строку веб-браузера.
Перейдите в Settings.
Перейдите в System -> Provisioning and configuration.
Вставьте скопированную в шаге 3 ссылке в поле Provisioning server.
Нажмите Set, а затем нажмите Start auto configuration.
Шаг 5. Регистрация DECT-трубок.
Введите IP-адрес базы в адресную строку веб-браузера.
Перейдите в Mobile Devices -> Administration.
Нажмите на значок карандаша для редактирования учетной записи.
Измените значение RegStatus на To register
Нажмите кнопку Register now.
Перейдите в Mobile Devices -> Registration Centre
Нажмите на кнопку Start Now
Нажмите на кнопку Регистрация на трубке и введите PIN код (по умолчанию 0000) для подтверждения регистрации.
К сожалению, DECT системы поддерживают не весь функционал 3CX и имеют следующие ограничения:
Нет поддержки STUN (возможно использовать только SBC)
Нет полной поддержки CTI (только звонки)
Нет LCD Language Provisioning
Нет возможности установить различные мелодии вызова для внешних вызовов, очередей или IVR
Нет поддержки 3CX Firmware Management
Нет поддержки Paging групп (включая Multicast)
Сегментная маршрутизация (Segment Routing, SR) может или не может считаться туннельным решением, в зависимости от конкретной реализации и того, насколько строго вы хотите придерживаться определения туннелей, представленного ранее в статье "Виртуализация сетей". В этой статье будет рассмотрена основная концепция сегментной маршрутизации и две возможные схемы реализации: одна с использованием меток потока IPv6, а другая с использованием меток многопротокольной коммутации по меткам (Multiprotocol Label Switching -MPLS).
Каждому устройству в сети с поддержкой SR присваивается уникальная метка. Стек меток, описывающий путь в терминах этих уникальных меток, может быть присоединен к любому пакету, заставляя его принимать определенный указанный путь. Рисунок 5 демонстрирует это.
Каждый маршрутизатор на рисунке 5 объявляет IP-адрес в качестве идентификатора вместе с меткой, прикрепленной к этому IP-адресу. В SR метка, прикрепленная к идентификатору маршрутизатора, называется идентификатором сегмента узла (SID узла). Поскольку каждому маршрутизатору в сети присваивается уникальная метка, путь через сеть может быть описан с использованием только этих меток. Например:
Если вы хотите перенаправить трафик от A к K по пути [B, E, F, H], вы можете описать этот путь с помощью меток [101,104,105,107].
Если вы хотите перенаправить трафик от A к K по пути [B, D, G, H], вы можете описать этот путь с помощью меток [101,103,106,107].
Набор меток, используемых для описания пути, называется стеком меток. Между D и H есть две связи; как это можно описать? В SR доступно несколько опций, в том числе:
Стек меток может включать в себя только идентификаторы SID узла, описывающие путь через сеть в терминах маршрутизаторов, как показано ранее. В этом случае, если бы стек меток включал пару [103,107], D просто перенаправлял бы H в обычном режиме на основе информации локальной маршрутизации, поэтому он будет использовать любой локальный процесс, который он будет использовать для пересылки любого другого пакета, например, распределение нагрузки между двумя каналами для пересылки трафика с меткой SR.
Стек меток может включать явную метку для загрузки общего ресурса по любому доступному набору путей, доступных в этой точке сети.
H может назначить метку для каждого входящего интерфейса, а также SID узла, привязанный к его локальному идентификатору маршрутизатора. Эти метки будут объявляться так же, как SID узла, но, поскольку они описывают смежность, они называются SID смежности (adjacency). SID смежности уникален локально; он уникален для маршрутизатора, объявляющего сам SID смежности.
Третий вид SID, префиксный SID, описывает конкретный достижимый пункт назначения (префикс) в сети. SID узла может быть реализован как SID префикса, привязанный к loopback адресу на каждом маршрутизаторе в сети.
Не обязательно, чтобы весь путь описывался стеком меток. Например, стек меток [101,103] будет направлять трафик в B, затем в D, но затем позволит D использовать любой доступный путь для достижения IP-адреса назначения в K. Стек меток [105] обеспечит прохождение трафика через сеть к K будет проходить через F. Не имеет значения, как трафик достиг этой точки в сети и как он был перенаправлен после того, как достигнет F, если он проходит через F, будучи направленным к K.
Каждая метка в стеке представляет собой сегмент. Пакеты переносятся от метки к метке через каждый сегмент в сети, чтобы быть транспортированными от головной части пути к хвостовой части пути.
Маршрутизация сегментов с многопротокольной коммутацией меток
MPLS был изобретен как способ сочетать преимущества асинхронного режима передачи (ATM), который больше не используется широко, с IP-коммутацией. В первые дни сетевой инженерии наборы микросхем, используемые для коммутации пакетов, были более ограничены в своих возможностях, чем сейчас. Многие из используемых наборов микросхем были Field Programmable Gate Arrays (FPGA), а не Application-Specific Integrated Circuits (ASIC), поэтому длина поля, в котором коммутировался пакет, напрямую коррелировала со скоростью, с которой пакет мог коммутироваться. Часто было проще переработать пакет или обработать его дважды, чем включать в заголовок много сложной информации, чтобы пакет можно было обработать один раз.
Примечание: повторное использование пакетов по-прежнему часто используется во многих наборах микросхем для поддержки внутренних и внешних заголовков или даже для обработки различных частей более длинного и сложного заголовка пакета.
MPLS инкапсулирует исходный пакет в заголовок MPLS, который затем используется для коммутации пакета по сети. На рисунке 6 показан заголовок MPLS. Весь заголовок состоит из 32 бит, метка 20 бит. Устройство пересылки MPLS может выполнять три операции:
Текущая метка в заголовке MPLS может быть заменена другой меткой (SWAP).
В пакет можно вставить новую метку (PUSH).
Текущая метка может быть очищена, а метка под текущей меткой обработана (POP).
Операции PUSH и POP переносятся непосредственно в SR: операция SWAP реализована в SR как CONTINUE, что означает, что текущая метка заменяется той же меткой (т. е. заголовок с меткой 100 будет заменен меткой 100), и обработка этого текущего сегмента будет продолжена. Проще всего понять процесс обработки на примере. Рисунок 7 демонстрирует это.
На рисунке 7 каждому маршрутизатору присвоена глобально уникальная метка из глобального блока сегментной маршрутизации (Segment Routing Global Block -SRGB). Они объявляются через протокол маршрутизации или другую плоскость управления. Когда A получает пакет, предназначенный для N, он выбирает путь через сеть, используя некоторый локальный механизм. В этот момент:
Чтобы начать процесс, A выполнит PUSH серии заголовков MPLS на пакете, которые описывают путь через сеть, [101,103,104,202,105,106,109, 110]. Когда A коммутирует пакет в сторону B, он вставит первую метку в стек, так как нет необходимости отправлять свою собственную метку в заголовке. Стек меток на канале [A,B] будет равен [103,104,202,105,106,109,110].
Когда B получает пакет, он проверяет следующую метку в стеке. Обнаружив, что метка равна 103, он выполнит POP этой метки и перешлет пакет в D. В этом случае стек меток SR выбрал один из двух возможных путей с равной стоимостью через сеть, так что это пример выбора SR конкретного пути. Стек меток на канале [B, D] будет [104,202,105,106,109,110].
Когда D получает пакет, верхняя метка в стеке будет 104. D выполнит POP этой метки и отправит пакет в E. Стек меток на канале [D, E] будет [202,105,106,109,110].
Когда E получает этот пакет, верхняя метка в стеке - 202. Это селектор смежности, поэтому он выбирает конкретный интерфейс, а не конкретного соседа. E выберет правильный интерфейс, нижний из двух интерфейсов на рисунке, и POP этой метки. Верхняя метка теперь представляет собой SID узла для F, который можно удалить, поскольку пакет передается на F. E переработает пакет и также откроет эту POP. Стек меток на канале [E, F] будет [106,109,110].
Когда пакет достигает F, следующей меткой в стеке будет 106. Эта метка указывает, что пакет должен быть передан в G. F выполнит POP метки и передаст ее G. Стек меток на канале [F, G] будет [109,110].
Когда пакет достигает G, следующая метка в стеке - 109, что указывает на то, что пакет должен быть направлен к L. Поскольку G не соединен напрямую с L, он может использовать локальный, свободный от петель (обычно самый короткий) путь к L. В этом случае есть два пути с равной стоимостью к L, поэтому G выполнит POP метки 109 и переадресовывает по одному из этих двух путей к L. В сегменте [G, L] стек меток равен [110].
Предположим, что G решает отправить пакет через K. Когда K получает пакет, он будет иметь стек меток, содержащий [110], который не является ни локальной меткой, ни смежным узлом. В этом случае метка должна оставаться прежней, или сегмент должен иметь CONTINUE. Чтобы реализовать это, K поменяет текущую метку 110 на другую копию той же метки, так что K будет пересылать трафик с той же меткой. На канале [K,L] стек меток будет равен [110].
Когда L принимает пакет, единственной оставшейся меткой будет 110, что указывает на то, что пакет должен быть направлен в M. L будет выполнена POP метки 109, эффективно удалив всю инкапсуляцию MPLS, и перенаправит пакет в M.
Когда M получает пакет, он пересылает его, используя обычный IP-адрес, в конечный пункт назначения - N.
Концепция стека меток в MPLS реализована в виде серии заголовков MPLS, уложенных друг на друга. Pop метки означает удаление самой верхней метки, push метки означает добавление нового заголовка MPLS в пакет, а continue означает замену метки идентичной меткой. Когда вы работаете со стопкой меток, понятия внутреннего и внешнего часто сбивают с толку, особенно, поскольку многие люди используют идею метки и заголовка как взаимозаменяемые. Возможно, лучший способ уменьшить путаницу - использовать термин "заголовок" для обозначения всего стека меток и исходного заголовка, переносимого внутри MPLS, при этом обращаясь к меткам как к отдельным меткам в стеке. Тогда внутренний заголовок будет исходным заголовком пакета, а внешний заголовок будет стеком меток. Внутренняя метка будет следующей меткой в стеке в любой момент прохождения пакета по сети, а внешняя метка будет меткой, по которой пакет фактически переключается.
Хотя в приведенном здесь примере используются IP-пакеты внутри MPLS, протокол MPLS предназначен для передачи практически любого протокола, включая Ethernet. Таким образом, SR MPLS не ограничивается использованием для передачи одного типа трафика, но может также использоваться для передачи кадров Ethernet по сети на основе IP / MPLS. Это означает, что SR можно использовать для поддержки первого варианта использования, обсуждаемого в этой статье, - предоставления услуг Ethernet по IP-сети.
MPLS - это туннель?
Много написанных и произнесенных слов были пролиты на вопрос о том, является ли MPLS протоколом туннелирования. Здесь туннелирование определяется как действие, а не протокол; это намеренная попытка отделить идею протокола туннелирования от концепции туннелирования как действия, предпринимаемого при передаче трафика через сеть. В случае MPLS это означает, что он может быть, а может и не быть протоколом туннелирования, в зависимости от того, как он используется - как и любой другой протокол. Например, если у вас есть стек меток, помещенных поверх пакета с IP-заголовком, внешняя метка, на которую коммутируется пакет, не является (технически) туннелем. Этот внешний заголовок в сети MPLS фактически является локальным для сегмента, поэтому он либо выталкивается, либо отправляется на каждом маршрутизаторе. Это аналогично заголовку Ethernet для каждого канала. Однако внутренний заголовок переносится в пакете MPLS и, следовательно, технически туннелируется. Внутренняя метка не используется на текущем устройстве для коммутации пакета; он просто переносится как часть пакета.
Это определение не идеально. Например, в случае MPLS SWAP или SR CONTINUE, используется ли метка для коммутации пакета или нет? Кроме того, в отличие от заголовка Ethernet в пакете, заголовок MPLS фактически используется при принятии решения о пересылке. Заголовок Ethernet, напротив, просто используется для достижения следующего перехода, а затем отбрасывается. Возможно, более подходящим сравнением было бы следующее: Заголовок MPLS подобен заголовку Ethernet, который используется для достижения перехода за пределы устройства, на которое маршрутизатор в настоящее время передает.
Независимо от этих ограничений, этого определения обычно достаточно, чтобы мысленно управлять различием между туннелированием и не туннелированием в MPLS, а также в большинстве других протоколов.
Перед тем как начать: почитайте про перераспределение между плоскостями управления в сетях.
Сетевые инженеры обычно думают, что плоскость управления выполняет самые разные задачи, от вычисления кратчайшего пути через сеть до распределения политики, используемой для пересылки пакетов. Однако идея кратчайшего пути проникает в концепцию оптимального пути. Точно так же идея политики также проникает в концепцию оптимизации сетевых ресурсов. Хотя важны и политика, и кратчайший путь, ни один из них не лежит в основе того, что делает плоскость управления. Задача плоскости управления - сначала найти набор путей без петель через сеть. Оптимизация - хорошее дополнение, но оптимизация может быть "сделана" только в контексте поиска набора путей без петель.
Таким образом, в этом разделе будет дан ответ на вопрос: как плоскость управления вычисляет пути без петель через сеть?
Этот цикл статей начнется с изучения взаимосвязи между кратчайшим или наименьшим метрическим путем и безцикловыми путями. Следующая рассматриваемая тема - свободные от циклов альтернативные пути (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, не вызывая состояния гонки? Два устройства могут выбрать друг друга в качестве следующего перехода к пункту назначения в один и тот же момент, а затем информировать друг друга в один и тот же момент, в результате чего оба одновременно выбирают другой путь. Результатом может быть либо стабильный набор путей без петель, когда два устройства циклически выбирают друг друга и не имеют пути к месту назначения, либо состояние насыщения, при котором нет пути к месту назначения.
Вторая проблема с этим механизмом - резюмирование - преднамеренное удаление информации о топологии сети для уменьшения количества состояний, переносимых на уровне управления. Плоскость управления будет иметь только метрики, с которыми можно работать, везде, где обобщается топология. Следовательно, лучше использовать правило, основанное на метриках или стоимости, а не на наборе узлов, через которые проходит путь.
Обратите внимание, что обе эти проблемы решаемы. На самом деле существуют алгоритмы вектора пути, которые полагаются на список узлов для вычисления путей без петель через сеть. Хотя эти системы широко распространены, они часто считаются слишком сложными для развертывания во многих ситуациях, связанных с проектированием сетей. Следовательно, широко используются системы на основе метрик или стоимости.
Теперь почитайте материал про построение деревьев в сетях