По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет рассмотрена настройка и подключение телефонного аппарата к АТС OpenScape Voice на примере телефонных аппаратов семейства Siemens OpenStage, работающих по протоколу SIP.
Для подключения нового абонента к системе требуются:
Префикс номера (Office Code) - префикс телефонного номера в системе, по которому осуществляется маршрутизация вызовов;
Полный внутренний номер (Home Directory Number) - состоит из префикса номера и внутреннего номера;
Внутренний номерной план (Private Numbering Plan) - определяет правила маршрутизации для группы абонентов;
Настойка параметров абонента (Subscriber);
Для конфигурации используется система управления - Common Management Portal. Она представлена в виде веб-портала.
Создание префикса номера
Для этого необходимо перейти в раздел Configuration → OpenScape Voice → Global Translation and Routing → Directory Numbers → Office Codes:
Номер телефона состоит из короткого внутреннего номера (Extension) и префикса - локального кода офиса (Local Office Code).
Нажимаем на кнопку Add… и поле Local Office Code указываем префикс, а ниже указываем диапазон внутренних номеров в полях Directory Number Start и Directory Number End. После нажимаем Save.
Создание внутреннего номера
Переходим в раздел Configuration → OpenScape Voice → Global Translation and Routing → Directory Numbers → Home Directory Numbers:
Нажимаем Add… и в поле Office Code указываем созданный префикс, а в полях Directory Number Start и Directory Number End указываем начальный и конченый диапазон номеров. Если необходимо добавить только один номер, то его нужно указать в поле Directory Number Start, а поле Directory Number End оставить пустым. Нажимаем Save, и номер появляется в списке.
Создание внутреннего номерного плана
Для этого в разделе Configuration → OpenScape Voice → Business Group → Private Numbering Plan List нажимаем на Add… и вводим название номерного плана. После этого в списке номерных планов можно нажать Set as Default для назначения планом по умолчанию.
Настойка параметров абонента
В разделе Configuration → OpenScape Voice → Business Group → Members → Subscribers нажимаем Add… и в открывшемся окне во вкладке General в поле Directory Number вводим полный номер абонента. Для корпоративной сети тип номера указываем Private.
Переходим на вкладку Displays и в поле Display Name вводе имя абонента, которое будет отображаться при звонках (для того чтобы отображалось имя на русском языке его нужно ввести в поле Unicode Display Name).
Далее во вкладке Connection в строке Type выставляем Dynamic, а в строке Transport Protocol - TCP и затем нажимаем на Save.
После первичной настройки для добавления новых абонентов используется только пункты создания внутреннего номера и настройки параметров, в которых указываются уже существующие префиксы и номерные планы.
Настройка параметров на телефоне
Перейдем к настройке самого телефонного аппарата. Телефон можно настроить либо через веб-интерфейс, набрав в адресной строке https://[ip адрес телефона], либо через меню самого аппарата.
Прежде всего необходимо проверить доступность телефона до OpenScape Voice. Это может сделать при помощи утилиты Ping, которая находится в меню Administrator → Diagnostics → Miscellaneous → IP tests. В этом же разделе можно произвести трассировку до необходимого адреса. Сетевые параметры можно изменить в разделе Network.
После проверки доступности необходимо перейти в раздел System → System Identity и в строке Terminal Number ввести полный номер абонента вместе с префиксом. В Display Identity можно указать номер, который будет высвечиваться на экране. После этого нажать Submit.
В соседнем разделе SIP interface нужно выбрать транспортный протокол, который мы ранее задавали в параметрах абонента (а данном случае TCP).
Далее в разделе Registration необходимо указать адреса интерфейса SIP системы OpenScape, в полях SIP server address и SIP registrar address. В поле server type выбираем OS Voice и нажимаем Submit.
После проведенных манипуляций на экране телефона высветится его номер.
Проверить регистрацию телефона можно через CMP в меню Configuration → OpenScape Voice → Business Group → Subscriber нажав на кнопку More и выпадающем меню выбрав пункт Registration Status. Далее в строке поиска выбрать критерий, ввести данные и нажать на Search. В результате будет показан статус регистрации телефона. Будет выведена информация о номере абонента, типе регистрации, статусе регистрации, IP адресе терминала и полном SIP адресе терминала.
Уровни выполнения (runlevel) Linux можно представить, как режим, в котором запускается система. Каждый из этих режимов обладают своими процессами, которые включены или выключены в зависимости от запущенного уровня выполнения. С момента загрузки Linux выполняется в одном из режимов, нельзя запускать систему в нескольких режимах, но есть возможность переключаться между уровнями во время работы на компьютере.
Например, при запуске системы с графическим интерфейсом выполняется один уровень, а если запускать систему в режиме командной строки выполнится другой. Это происходит потому, что режиму GUI нужны доступы к тем процессам, в которых командная строка не нуждается. В зависимости от того, какие службы нужно включить, а какие выключить система меняет уровни выполнения.
Почему важны уровни доступа
Вы можете годами пользоваться системой Linux, даже не понимая разницу между уровнями доступа, так как эта опция не является часто конфигурируемой.
Тем не менее уровни выполнения Linux дают администраторам повышенный контроль над системой.
Режим, в котором работает система, может быть изменен (как это сделать будет показано далее), как и сервисы, которые выполняются в этом режиме. Это позволяет нам полностью контролировать, к каким службам система будет иметь доступ в данный момент.
Сколько уровней выполнения существует?
В системе Linux есть семь уровней выполнения, которые нумеруются от 0 до 6. Разные дистрибутивы по-разному используют уровни выполнения, так что очень сложно составить список задач, которые выполняет конкретный уровень.
Зато вы сами можете посмотреть какие задачи выполняют уровни доступа вашего дистрибутива. Ниже приведён список уровней выполнения и основных задач, выполняемых ими.
Runlevel 0 завершает работу системы
Runlevel 1 однопользовательский режим работы. Чаще всего используется в целях обслуживания и выполнения других административных задач. Это уровень также может называться runlevel S, где S означает single-user. Если вам когда-то приходилось сбрасывать пароль на Linux, то вы вероятно уже пользовались этим режимом.
Runlevel 2 многопользовательский режим работы без поддержки сетевых служб (демонов).
Runlevel 3 многопользовательский режим с поддержкой сети, но без графического интерфейса. Чаще всего серверные версии Linux работают именно на этом уровне выполнения.
Runlevel 4 не используется. Пользователь может настраивать этот уровень исходя из его целей. О том, как это сделать также будет рассказано далее.
Runlevel 5 этот режим схож с уровнем 3, но тут еще запускается графический интерфейс. В этом режиме работают десктопные версии Linux.
Runlevel 6 этот уровень перезагружает систему.
Как узнать текущий режим работы?
Чтобы узнать текущий уровень выполнения достаточно ввести команду runlevel в командной строке.
На выводе этой команды две цифры. Первая указывает на предыдущий режим работы, а второй на текущий. На скриншоте вместо первой цифры указана буква N, что значит система изначально запускалась и работает в 5 режиме, о чём говорит вторая цифра 5.
Как менять уровень выполнения?
Текущий уровень выполнения можно менять командой "telinit". Ниже приведён пример смены уровня выполнения на CentOS.
$ telinit 3
Следует отметить, что эта операция требует прав привилегированного пользователя. Имейте ввиду, что на системах семейства Debian уровни выполнения работают по-другому. Например, Ubuntu в режиме командой строки запускается с уровнем выполнения 5.
После выполнения команды указанной выше, ваш экран может стать пустым. Это потому, что вы остались на пустом терминале, чтобы вернутся на рабочий терминал нажмите комбинацию клавиш Alt+F1.
Если запустить команду runlevel еще раз, то мы увидим, что текущий уровень выполнения 3, а предыдущий 5.
Linux system против runlevels
В последние годы systemd сменила многолетнюю систему уровней доступа (System V init). Фактически он работает по тому же принципу, но использует новые команды, которые в целом используют "runlevel" как "target".
Runlevel 0 = poweroff.target (runlevel0.target)
Runlevel 1 = rescue.target (runlevel1.target)
Runlevel 2 = multi-user.target (runlevel2.target)
Runlevel 3 = multi-user.target (runlevel3.target)
Runlevel 4 = multi-user.target (runlevel4.target)
Runlevel 5 = graphical.target (runlevel5.target)
Runlevel 6 = reboot.target (runlevel6.target)
По ходу статьи мы изучим systemd и его команды.
Как поменять уровень выполнения по умолчанию?
Может быть очень много причин для того чтобы загружаться с другим уровнем выполнения. Например, системные администраторы в основном используют систему в режиме командой строки, включая графический интерфейс только в случае необходимости.
Именно для таких случаев нужно убедиться, что уровень выполнения по умолчанию 3, а не 5.
В прошлом для этого приходилось редактировать файл /etc/inittab. Вы еще можете увидеть эту практику на некоторых системах. Если вы работаете с ОС, которые давно не обновляются до новых версий, этот путь будет приемлемым.
$ vi /etc/inittab
На скриншоте уровнем выполнения по умолчанию установлен 5.
Но большинство систем Linux отказались от файла /etc/inittab в пользу systemd targets и мы рассмотрим разницу между ними по ходу статьи.
Вы можете не найти в своей системе файл /etc/inittab или же файл inittab выведет вам сообщение с советом использовать systemd.
Чтобы проверить текущий уровень выполнения по умолчанию введите команду
$ systemctl get-default
Система вернула нам "graphical.target". Как вы наверное и догадались, это не что иное, как уровень выполнения 5.
Чтобы просмотреть остальные "target" и уровни выполнения, ассоциированные с ними введите команду:
$ ls -l /lib/systemd/system/runlevel*
Символьные ссылки указывают на то, что systemd работают так же как и runlevel. Итак, что необходимо сделать, чтобы поменять уровень выполнения по умолчанию? Для этого достаточно создать новую символьную ссылку на интересующую нас цель systemd.
$ ln -sf /lib/systemd/system/runlevel3.target /etc/systemd/system/default.target
Данной командой мы поменяли режим запуска системы по умолчанию с уровня выполнения 5, на 3 и при следующей загрузке система выполнить именно этот уровень.
Ключ f указывает на то, что перед созданием новой символьной ссылки целевой файл должен быть удален. Это же самое могли бы сделать командой rm.
Чтобы проверит успешно ли применились изменения достаточно повторно ввести команду "systemctl get-default".
Разница между уровнями выполнения 3 и 5
Самыми часто используемыми уровнями выполнения являются уровни 3 и 5. В целом их разница сводится к тому, что 3 это режим командной строки, а 5 режим графического интерфейса.
Конечно, не во всех дистрибутивах выполняется это условие или же ваша система может быть сконфигурирована так, что эти два уровня имеют больше отличий. Дальше мы рассмотрим, как узнать, какие процессы задействованы для того или иного уровня.
Просмотр список служб конкретного уровня
Чтобы просмотреть список служб, доступных для каждого уровня до недавнего времени использовалась команда "chkconfig -list". Если у вас стоит одна из последний версий, системы, то вероятно вы получите ошибку, как на скриншоте ниже:
Чтобы проверить, какие службы запускаются во время загрузки системы в режиме графического интерфейса (уровень выполнения 5 для семейства RedHat), нужно запустить следующую команду:
$ systemctl list-dependencies graphical.target
Чтобы просмотреть список доступных служб другого уровня, просто замените "graphical.target" на нужную.
Под каким уровнем работает процесс
Если нужно посмотреть по каким уровнем выполнения запущена та или иная служба, можно ввести команду:
$ systemctl show -p WantedBy [name of service]
Например, чтобы посмотреть какой runlevel использует служба sshd, введите команду:
$ systemctl show -p WantedBy sshd.service
Судя по скриншоту выше, служба sshd запушена под уровнями 2,3 и 4 (multi-user.target)
Меняем уровень запуска приложения
Как было показано выше, демон SSH запущена только на уровнях 2-4. Что если нам нужно, чтобы он работал ещё и на уровне 5? Для этого нужно ввести следующее изменение:
$ systemctl enable sshd.service
Проблемы безопасности с уровнями доступа Linux
Как было сказано ранее, уровни доступа дают администраторам возможность управлять службами, которые работают в определённых случаях. Такая возможность детального контроля повышает безопасность системы, так как системный администратор может быть уверен, что не запущена ни одна сторонняя служба.
Проблема возникает, когда администратор не знает точно какие службы запущены и, следовательно, не может принять меры по уменьшению площади атаки.
Используя методы из данного руководства, вы можете настроить уровень выполнения по умолчанию и контролировать запущенные приложения. Это, конечно, не уменьшит нагрузку на системные ресурсы, но сервер будет более защищен.
Помните, что надо запускать тот уровень, который вам необходим. Нет смысла запускать систему в графическом режиме, если планируете работать там режиме командной строки.
Каждый уровень выполнения запускает новые службы, большинство из которых работают в фоновом режиме, и вы можете забыть обезопасить их.
Какой уровень выполнения выбрать?
Выбор режима запуска системы полностью зависит от ситуации. В основном используется один из двух режимов: либо runlevel 3, либо runlevel 5.
Если вам удобно работать с командной строкой и вам не нужен графический интерфейс, то уровень выполнения 3 самый подходящий.
Это предотвратит запуск ненужных служб. С другой стороны, если вам хочется работать в десктопном режиме или же вам нужна графическая оболочка для работы какой-то программы, то выберите уровень 5.
Если же нужно запустить систему в режиме обслуживания, то выбирайте уровень 1. В этом режиме в системе будете только вы, так как сетевые службы даже не запущены. Это позволит выполнить обслуживания без сбоя.
В редких случаях появляется необходимость использовать уровень выполнения 4. Это может быть только в том случае, если администратору нужен уровень выполнения для особых задач.
Как вы уже, наверное, заметили, мы не может запускать систему с уровнем 0 и 6, но можно переключаться на них если нужно выключить или перезагрузить систему. Но в этом нет особой необходимости, так как есть команды, которые выполняют эти операции.
Можно ли создано новый уровень на Linux?
Так как система Linux это система бесконечных возможностей, то и создание нового уровня не исключение. Но очень маловероятно, что вам когда-нибудь понадобится это. Но если вы все-таки решили создать новый уровень, то следует начать с копирования существующего уровня и изменения её под свои задачи.
Целевые уровни расположены по следующему пути:
/usr/lib/systemd/system
Если хотите создать свой уровень на основе 5-го уровня выполнения, скопируйте искомую директорию в новую:
$ cp /usr/lib/systemd/system/graphical.target /usr/lib/systemd/system/mynew.target
Затем в новой директории создайте поддиректорую "wants":
$ mkdir /etc/systemd/system/mynew.target.wants
Затем просто создайте символьную ссылку на дополнительные службы в директории /usr/lib/systemd/system, которые необходимы вашему уровню.
В первой части статей о протоколе Border Gateway Protocol (BGP) мы узнали и разобрали протокол BGP, а затем изучили типы сообщений BGP и состояния соседства. Сегодня, в этой статье, вы узнаете об одном из самых сложных аспектов BGP: как он принимает решение о выборе маршрута.
В то время как протоколы маршрутизации, такие как RIP, OSPF и EIGRP, имеют свои собственные метрики, используемые для выбора «лучшего» пути к целевой сети, BGP использует коллекцию атрибутов пути (PAs).
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Видео: Основы BGP за 7 минут
BGP- атрибуты пути (Path Attributes)
Когда ваш спикер BGP получает BGP префикс, к нему будет прикреплено множество атрибутов пути, и мы знаем, что они будут иметь решающее значение, когда речь заходит о том, чтобы BGP выбрал самый лучший путь к месту назначения.
Все атрибуты BGP- маршрута, делятся на четыре основные категории.
Well-Known Mandatory
Well-Known Discretionary
Optional Transitive
Optional Non-Transitive
Обратите внимание, что две категории начинаются с термина Well-Known. Well-Known означает, что все маршрутизаторы должны распознавать этот атрибут пути. Две другие категории начинаются с термина Optional. Optional означает, что реализация BGP на устройстве вообще не должна распознавать этот атрибут.
Тогда у нас есть термины mandatory и discretionary, связанные с термином Well-Known. Mandatory означает, что обновление должно содержать этот атрибут. Если атрибута нет, тогда появится сообщение об ошибке уведомления, и пиринг будет удален. Discretionary, конечно, будет означать, что атрибута не должно быть в обновлении.
У необязательных категорий атрибутов есть- транзитивные и нетранзитивные. Если он транзитивен, то устройство должно передать этот атрибут пути своему следующему соседу. Если он не является транзитивным, то может просто игнорировать это значение атрибута.
Пример 1 показывает проверку нескольких атрибутов пути для префикса, который был получен маршрутизатором TPA1 от маршрутизатора ATL. Обратите внимание, что мы используем команду show ip bgp для просмотра этой информации, которая хранится в базе данных маршрутизации BGP. В частности, этот вывод показывает атрибуты Next Hop, Metric (MED), LocPrf (Local Preference), Weight, и Path (AS Path).
TPA1#show ip bgp
BGP table version is 4, local router ID is 10.10.10.1
Status codes: s suppressed, d damped, h history, * valid, > best, i – internal, r RIB-failure, S Stale
Origin codes^ I – IGP, e – EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
*> 100.100.100.0/24 10.10.10.2 0 200 i
Атрибут Origin
Атрибут ORIGIN в BGP-это попытка записать, откуда пришел префикс. Существует три возможности, когда речь заходит о происхождении этого атрибута: IGP, EGP и Incomplete. Как видно из легенды примера 1, коды, используемые Cisco для этих источников, являются i, e, и ?. Для префикса, показанного в примере 1, можно увидеть, что источником является IGP. Это указывает на то, что префикс вошел в эту топологию благодаря сетевой команде внутри конфигурации этого исходного устройства. Далее в этой статье мы рассмотрим сетевую команду во всей ее красе. Термин IGP здесь предполагает, что префикс произошел от записи протокола внутреннего шлюза (Gateway Protocol). Допустим, у нас есть префикс в нашей таблице маршрутизации OSPF, а затем мы используем сетевую команду внутри BGP, чтобы поместить его в экосистему BGP. Конечно, IGP - не единственный источник префиксов, которые могут нести этот атрибут. Например, вы можете создать локальный интерфейс обратной связи на устройстве, а затем использовать сетевую команду для объявления этого локального префикса в BGP.
EGP ссылается на ныне устаревший протокол внешнего шлюза (Exterior Gateway Protocol), предшественник BGP. В результате вы не увидите этот исходный код.
Incomplete означает, что BGP не уверен в том, как именно префикс был введен в топологию. Наиболее распространенным сценарием здесь является то, что префикс был перераспределен в Border Gateway Protocol из какого-то другого протокола, обычно IGP.
Возникает вопрос, почему исходный код имеет такое значение. Ответ заключается в том, что это ключевой фактор, когда BGP использует свой алгоритм для выбора наилучшего пути к месту назначения в сети. Он может разорвать «связи» между несколькими альтернативными путями в сети. Мы также уделяем этому атрибуту большое внимание, потому что это действительно один из хорошо известных, обязательных атрибутов, которые должны существовать в наших обновлениях.
Атрибут AS Path
AS Path - это well-known mandatory атрибут. Он очень важен для наилучшего поиска пути, а также для предотвращения петель внутри Border Gateway Protocol.
Рассматривая нашу топологию, показанную на рисунке 1, рассмотрим префикс, возникший в TPA. Обновление отправляется в TPA1, и TPA не добавляет свой собственный AS 100 в AS Path, так как сосед, которому он отправляет обновление, находится в своем собственном AS в соответствии с пирингом iBGP.
Когда TPA1 отправляет обновления на ATL, он добавляет номер 100 в обновления. Следуя этой логике, ATL отправит обновления на ATL2 и не будет добавлять свой собственный номер в качестве AS. Это будет работать до тех пор, пока ATL2 не отправит обновления на какой-то другой AS, предшествующий AS 200. Это означает, что, когда мы рассматриваем образец AS path, как показано в примере 2, крайним правым в пути является AS, который первым создал префикс (100), а крайним левым- AS, который доставил префикс на локальное устройство (342).
Пример 2: Пример BGP AS Path
Атрибут Next Hop
На самом деле нет ничего удивительного в том, что префикс BGP имеет атрибут под названием Next Hop. В конце концов, маршрутизатор должен знать, куда отправлять трафик для этого префикса. Next Hop атрибут удовлетворяет эту потребность. Интересным моментом здесь, однако, является тот факт, что Next Hop в BGP работает не так же, как это происходит в большинстве IGP. Также следует отметить, что правила меняются, когда вы рассматриваете iBGP в сравнении с eBGP.
При рассмотрении протокола внутреннего шлюза, когда устройство отправляет обновление своему соседу, значением Next Hop по умолчанию является IP-адрес интерфейса, с которого отправляется обновление. Этот параметр продолжает сбрасываться каждым маршрутизатором по мере прохождения обновления через топологию. Next Hop принимает простую парадигму «hop-by-hop».
С помощью BGP, когда у нас есть пиринг eBGP и отправляется префикс, Next Hop действительно будет (по умолчанию) IP-адресом спикера eBGP, отправляющего обновление. Однако IP-адрес этого спикера eBGP будет сохранен в качестве Next Hop, поскольку префикс передается от спикера iBGP к спикеру iBGP. Очень часто мы видим атрибут Next Hop, являющийся IP-адресом, который не является устройством, передавшим нам обновление. Это действительно адрес, который представляет собой соседний AS, который предоставил нам префикс. Таким образом, правильно думать о BGP как о протоколе «AS-to-AS» вместо протокола «hop-to-hop».
Это может вызвать определенные проблемы. Основной вывод состоит в том, что вы должны гарантировать, что все ваши спикеры BGP могут достичь значения Next Hop указанного в атрибуте, чтобы путь считался допустимым. Иначе говоря, спикеры BGP будут считать префикс недопустимым, если они не смогут достичь значения Next Hop.
К счастью, эту проблему можно обойти. Вы можете взять устройство iBGP и проинструктировать его, установив себя в качестве значения Next Hop всякий раз, когда вам это нужно. Это делается с помощью манипуляции пирингом командой neighbor, как показано в примере 3.
ATL (config)# router bgp 200
ATL (config-router)# neighbor 10.10.10.1 next-hop-self
Атрибут BGP Weight (веса)
Weight (вес) - это очень интересный атрибут BGP, так как он специфичен для Cisco. Хорошая новость заключается в том, что, поскольку Cisco является гигантом в отрасли сетей, то многие другие производители будут поддерживать использование Weight в качестве атрибута.
Weight также является одним из самых уникальных атрибутов, поскольку это значение не передается другим маршрутизаторам. Weight - это значение, которое присваивается нашим префиксам как локально значимое значение. Weight - это простое число в диапазоне от 0 до 65535, и чем выше значение веса, тем выше предпочтение этого пути. Когда префикс генерируется локально, он будет иметь вес 32768. В противном случае вес префикса по умолчанию равен 0.
Как можно использовать вес? Поначалу это покажется странным, так как он не передается другим спикерам BGP. Однако все просто. Допустим, ваш маршрутизатор получает один и тот же префикс от двух разных автономных систем, с которыми он работает. Если администратор хочет предпочесть один из путей по какой-либо причине, он может манипулировать локальным значением веса на предпочтительном пути и мгновенно влиять на процесс принятия решения о наилучшем пути BGP.
BGP Best Path (выбор лучшего пути)
Как было сказано ранее, мы знаем, что у IGP есть метрическое значение, которое является ключевым для определения наилучшего пути к месту назначения. В случае с OSPF эта метрика основана на стоимости, которая основана на пропускной способности. У BGP существует множество атрибутов пути, которые может иметь префикс. Все они поддаются алгоритму выбора наилучшего пути BGP. На рисунке 2 показаны шаги (начиная сверху), которые используются в выборе наилучших путей Cisco BGP.
Изучая эти критерии выбора пути, вы можете сразу же задаться вопросом, почему он должен быть таким сложным. Помните, когда мы имеем дело с чем-то вроде интернета, мы хотим, чтобы было как можно больше регулировок для политики BGP. Мы хотим иметь возможность контролировать, насколько это возможно, как префиксы используются совместно и предпочтительно в такой большой и сложной сети.