пїЅпїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Группы вызовов (звонящие группы) – это объединенные под едиными правилами телефонные аппараты. Такой функционал очень удобен, когда вызов необходимо распределить между определенным пулом телефонов по заранее настроенным правилам. Например, вы хотите чтобы 2 телефона звонили одновременно при входящем звонке, или звонили поочередно – эта настройка реализуется с помощью ринг – групп. На номер группы можно позвонить с офисного IP – телефона, что делает ее функционал еще более удобным.
Необходимые настройки
Для создания ринг-группы в Elastix необходимо открыть следующую вкладку:
PBX → PBX Configuration → Ring Groups. Вы автоматически попадёте в окно создания новой ринг-группы (скриншот ниже).
Производим настройку следующих параметров:
Ring-Group Number - Название ринг-группы
Group description – описание, например «sales»
Ring Strategy – важный пункт, так как он определяет алгоритм обзвона ринг-группы, их описания в конце статьи;
Ring Time – количественная характеристика в секундах, определяет сколько по времени будет идти вызов на данную группу
Extension list – список экстеншенов, на которые будет маршрутизироваться вызов. Важный момент – кроме непосредственно экстеншенов сюда можно добавить любые номера, которые настроены в исходящих маршрутах, но если номер не является экстеншеном, после него необходимо поставить # (решётку) – к примеру, 89162998979#.
Так же рассмотрим остальные поля:
Extension Quick Pick – инструмент для добавления экстеншенов в список, экстеншен добавится в конец списка.
Announcement – голосовое или музыкальное приветствие в случае попадания вызова в данную группу
Play Music on Hold – включение или выключение MoH (мелодия на удержании вызова)
CID Name Prefix - описательный префикс, который будет высвечиваться при звонке на внутренние телефоны, к примеру: Sales:Igor Zamochnikov
Ignore CF Settings – экстеншены, которые будут совершать попытку перевести поступающий вызов будут проигнорированы, включается галочкой.
Skip Busy Agent – вызов будет пропускать экстеншен, который в данный момент участвует в разговоре
Enable Call Pickup – возможность «поднять» вызов с использованием номера ринг-группы
Одним из достаточно интересных параметров так же является Confirm Calls – подтверждение вызовов удаленной стороной по нажатию единицы – до момента нажатия разговор не начнется. Опция доступна только для стратегии ringall.
Remote Announce – сообщение, которое будет проигрываться принимающей стороне если включена опция Confirm Calls
Too-Late Announce – сообщение, которое будет проигрываться принимающей стороне, если она взяла трубку до нажатия на 1. Так же используется только вместе с включенной опцией подтверждения вызова.
Call Recording - Включение записи разговоров в данной ринг-группе
Destination if no answer – в данном примере по истечению таймаута вызов будет сброшен.
Ниже приведен пример настроенной ринг-группы:
После этого необходимо нажать Submit Changes и Apply Config.
Нужно иметь в виду – номер ринг-группы становится практически тем же номером экстеншена, но с некоторым ограничениями. То есть на этот номер можно будет позвонить с телефона, указать его как цель в IVR и так далее. Теперь давайте разберемся с параметрами распределения вызовов внутри самой группы:
ringall: Вызов поступает на все номера, указанные в настройках ринг-группы одновременно (настройка по умолчанию)
hunt: Вызов поочередно проходит через каждый номер
memoryhunt: Вызов начинается с первого номера в списке, затем звонит 1й и 2й, затем 1й, 2й и 3й, и так далее.
*-prim: Режимы с данной припиской работают, как и описанные выше, с одним отличием – если первый номер в списке занят, вызов прекратится
firstavailable: вызов поступает на первый незанятый канал
firstnotonphone: вызов поступает на первый телефон, на котором не снята трубка
random: Вызов поступает на указанные номера с определенным приоритетом так, чтобы вызовы распределялись относительно равномерно. Имитирует очередь (Queue) в те моменты, когда очередь не может быть использована.
Как хороший разработчик на JavaScript, вы стремитесь писать чистый, надежный и поддерживаемый код. Возможно, вы замечали, что пишете код для одной задачи, а он похож на решение для совершенно другой проблемы, с которой вы могли сталкиваться ранее. Вы можете не знать об этом, но вы использовали паттерн проектирования.
Преимущества шаблонов проектирования:
Решения проверены временем. Поскольку паттерны проектирования часто используются многими разработчиками, вы можете быть уверены, что они работают. Плюс они неоднократно пересматривались и, возможно, уже оптимизированы.
Легко поддаются многократному использованию. Паттерны проектирования документируют многоразовое решение, которое может быть изменено для решения множества конкретных задач, поскольку они не привязаны к конкретной проблеме.
Облегчают коммуникацию. Когда разработчики знакомы с паттернами проектирования, им легче общаться друг с другом по поводу потенциальных решений той или иной проблемы.
Нет необходимости рефакторинга кода. Если приложение написано с учетом паттернов проектирования, часто бывает так, что в дальнейшем вам не придется рефакторить код, потому что применение правильного паттерна проектирования к конкретной задаче уже является оптимальным решением.
Уменьшают размер кодовой базы. Поскольку паттерны проектирования обычно представляют собой элегантные и оптимальные решения, они обычно требуют меньше кода, чем другие решения.
Краткая история JavaScript
JavaScript - один из самых популярных на сегодняшний день языков программирования для веб-разработки. Изначально он был создан как своего рода «клей» для различных отображаемых HTML-элементов, известный как язык сценариев на стороне клиента, для одного из первых веб-браузеров. Он назывался Netscape Navigator и в то время мог отображать только статический HTML. Как вы уже догадались, идея создания такого языка сценариев привела к войне за браузер между крупными игроками в индустрии разработки браузеров, такими как Netscape Communications (сегодня Mozilla), Microsoft и другими.
Каждый из крупных игроков хотел продвинуть свою собственную реализацию этого языка сценариев, поэтому Netscape создал JavaScript (на самом деле это сделал Брендан Эйх), Microsoft - JScript и так далее. Как вы понимаете, различия между этими реализациями были очень велики, поэтому разработка для веб-браузеров велась для каждого браузера, с использованием стикеров, которые прилагались к веб-странице. Вскоре стало ясно, что нам нужен стандарт, кроссбраузерное решение, которое унифицировало бы процесс разработки и упростило создание веб-страниц. То, что они придумали, называется ECMAScript.
ECMAScript - это стандартизированная спецификация языка сценариев, которую стараются поддерживать все современные браузеры. Существует множество реализаций (можно сказать, диалектов) ECMAScript. Самый популярный из них - JavaScript, о котором пойдет речь в этой статье. С момента своего появления ECMAScript стандартизировал множество важных вещей, и для тех, кто интересуется конкретикой, в Википедии есть подробный список стандартизированных вещей для каждой версии ECMAScript. Поддержка браузерами ECMAScript версии 6 (ES6) и выше все еще не завершена и для полноценной поддержки должна быть транспилирована в ES5.
Что такое JavaScript?
JavaScript - это легкий, интерпретируемый, объектно-ориентированный язык программирования с первоклассными функциями, наиболее известный как язык сценариев для веб-страниц.
Вышеупомянутое определение означает, что код JavaScript занимает мало памяти, прост в реализации и легко изучается, а его синтаксис схож с такими популярными языками, как C++ и Java. Это скриптовый язык, что означает, что его код интерпретируется, а не компилируется. Он поддерживает процедурный, объектно-ориентированный и функциональный стили программирования, что делает его очень гибким для разработчиков.
Итак, мы рассмотрели все характеристики, которые похожи на многие другие языки, поэтому давайте посмотрим, что особенного есть в JavaScript по сравнению с другими языками. Я перечислю несколько характеристик и постараюсь объяснить, почему они заслуживают особого внимания.
JavaScript поддерживает функции как объекты первого класса
Это означает, что вы можете передавать функции в качестве параметров другим функциям точно так же, как и любую другую переменную. Этот код складывает два числа, а затем передает результат в колбэк-функцию, которая выводит его в консоль.
JavaScript основан на прототипах
Как и во многих других объектно-ориентированных языках, JavaScript поддерживает объекты, и одно из первых понятий, которое приходит на ум при работе с объектами, — это классы и наследование. Здесь возникает некоторая сложность, так как язык не поддерживает классы в своей базовой форме, а использует то, что называется прототипным или экземплярным наследованием.
Только в ES6 был введен формальный термин "класс", что означает, что браузеры еще не полностью поддерживают его (если помните, на момент написания последняя полностью поддерживаемая версия ECMAScript — 5.1). Важно отметить, что, даже несмотря на то, что термин "класс" введен в JavaScript, под капотом он все равно использует прототипное наследование.
Прототипное программирование — это стиль объектно-ориентированного программирования, в котором повторное использование поведения (известное как наследование) осуществляется через процесс повторного использования существующих объектов посредством делегаций, которые служат прототипами. Мы подробнее рассмотрим это, когда перейдем к разделу о шаблонах проектирования, так как эта особенность используется во многих шаблонах проектирования в JavaScript.
Циклы событий JavaScript
Если у вас есть опыт работы с JavaScript, вы наверняка знакомы с термином «функция обратного вызова». Для тех, кто не знаком с этим термином, функция обратного вызова - это функция, передаваемая в качестве параметра (помните, что JavaScript рассматривает функции как граждан первого класса) другой функции и выполняемая после наступления события. Обычно она используется для подписки на такие события, как щелчок мыши или нажатие кнопки клавиатуры.
Каждый раз, когда происходит событие, к которому привязан обработчик (иначе событие теряется), сообщение отправляется в очередь сообщений, которые обрабатываются синхронно в порядке FIFO (первым пришел — первым обработан). Это называется циклом событий (event loop).
Каждое сообщение в очереди связано с определенной функцией. Когда сообщение извлекается из очереди, среда выполнения полностью выполняет функцию, прежде чем обработать следующее сообщение. Это означает, что если функция вызывает другие функции, они все будут выполнены до того, как будет обработано новое сообщение из очереди. Это называется выполнением до завершения (run-to-completion).
queue.waitForMessage() синхронно ожидает новые сообщения. Каждое обрабатываемое сообщение имеет свой собственный стек и обрабатывается до тех пор, пока стек не опустеет. Когда выполнение завершено, из очереди берется новое сообщение, если оно есть.
Вы, возможно, слышали, что JavaScript является неблокирующим, что означает, что когда выполняется асинхронная операция, программа способна обрабатывать другие задачи, например, принимать ввод от пользователя, ожидая завершения асинхронной операции, не блокируя основной поток выполнения. Это очень полезное свойство JavaScript, и можно было бы написать целую статью только на эту тему; однако это выходит за рамки данного материала.
Что такое паттерн проектирования в JavaScript?
Как я уже говорил, паттерны проектирования - это многократно используемые решения часто встречающихся проблем при проектировании программного обеспечения. Давайте рассмотрим некоторые категории паттернов проектирования.
Прото-паттерн
Как создается паттерн? Допустим, вы распознали часто встречающуюся проблему, и у вас есть собственное уникальное решение этой проблемы, которое не признано и не задокументировано во всем мире. Вы используете это решение каждый раз, когда сталкиваетесь с этой проблемой, и считаете, что его можно использовать повторно и что сообщество разработчиков может извлечь из него пользу.
Станет ли оно сразу же шаблоном? К счастью, нет. Часто бывает так, что человек имеет хорошую практику написания кода и просто принимает что-то, что выглядит как паттерн, за паттерн, когда на самом деле это не паттерн.
Как узнать, что то, что вы думаете, что узнали, на самом деле является шаблоном?
Узнав мнение других разработчиков об этом, ознакомившись с процессом создания паттерна и хорошо изучив существующие паттерны. Существует этап, через который должен пройти паттерн, прежде чем он станет полноценным, и называется он прото-паттерн.
Прото-паттерн является будущим паттерном, если он проходит определенный период тестирования различными разработчиками и сценариями, в которых паттерн оказывается полезным и дает правильные результаты. Для того чтобы полноценный паттерн был признан сообществом, необходимо проделать довольно большой объем работы и документирования - большая часть которого выходит за рамки этой статьи.
Антипаттерн
Как паттерн проектирования представляет собой хорошую практику, так и антипаттерн представляет собой плохую практику.
Примером антипаттерна может служить модификация прототипа класса Object. Почти все объекты в JavaScript наследуются от Object (помните, что JavaScript использует наследование по прототипу), поэтому представьте себе сценарий, в котором вы изменили этот прототип. Изменения прототипа Object будут видны во всех объектах, которые наследуют от этого прототипа - а это большинство объектов JavaScript. Это катастрофа, которая только и ждет, чтобы произойти.
Другой пример, похожий на упомянутый выше, - изменение объектов, которые вам не принадлежат. Примером может служить переопределение функции объекта, используемого во многих сценариях в приложении. Если вы работаете с большой командой, представьте, какую путаницу это вызовет; вы быстро столкнетесь с коллизиями в наименованиях, несовместимыми реализациями и кошмарами обслуживания.
Подобно тому, как полезно знать обо всех хороших практиках и решениях, очень важно знать и о плохих. Таким образом, вы сможете распознать их и избежать ошибок.
Категоризация паттернов проектирования
Шаблоны дизайна можно классифицировать множеством способов, но наиболее популярными являются следующие:
Творческие паттерны проектирования
Структурные паттерны проектирования
Поведенческие шаблоны проектирования
Конкурентоспособные шаблоны проектирования
Архитектурные шаблоны проектирования
Паттерны креативного проектирования
Эти паттерны касаются механизмов создания объектов, которые оптимизируют создание объектов по сравнению с базовым подходом. Базовая форма создания объектов может привести к проблемам в проектировании или к увеличению сложности проекта. Паттерны креативного проектирования решают эту проблему, каким-то образом управляя созданием объектов. Некоторые из популярных паттернов проектирования в этой категории:
Метод фабрики
Абстрактная фабрика
Конструктор
Прототип
Синглтон
Структурные паттерны проектирования
Эти паттерны связаны с отношениями между объектами. Они гарантируют, что при изменении одной части системы, вся система не должна меняться вместе с ней. Наиболее популярными паттернами в этой категории являются:
Адаптер
Мост
Композит
Декоратор
Фасад
Flyweight
Прокси
Поведенческие паттерны проектирования
Эти шаблоны распознают, реализуют и улучшают связь между разрозненными объектами в системе. Они помогают обеспечить синхронизацию информации между разрозненными частями системы. Популярными примерами таких паттернов являются:
Цепочка ответственности
Команда
Итератор
Посредник
Memento
Наблюдатель
Состояние
Стратегия
Посетитель
Конкурентоспособные шаблоны проектирования
Эти типы паттернов проектирования связаны с парадигмами многопоточного программирования. Некоторые из них популярны:
Активный объект
Ядерная реакция
Планировщик
Архитектурные шаблоны проектирования
Шаблоны проектирования, которые используются в архитектурных целях. К наиболее известным из них относятся:
MVC (Model-View-Controller)
MVP (Model-View-Presenter)
MVVM (Model-View-ViewModel).
В следующем разделе мы подробно рассмотрим некоторые из вышеупомянутых паттернов проектирования с примерами для лучшего понимания.
Примеры шаблонов проектирования
Каждый из паттернов проектирования представляет собой определенный тип решения конкретной проблемы. Не существует универсального набора паттернов, который бы всегда подходил лучше всего. Нам нужно узнать, когда тот или иной паттерн окажется полезным и принесет ли он реальную пользу. Как только мы познакомимся с паттернами и сценариями, для которых они лучше всего подходят, мы сможем легко определить, подходит ли конкретный паттерн для решения конкретной проблемы.
Помните, что применение неправильного паттерна для решения конкретной задачи может привести к таким нежелательным последствиям, как излишнее усложнение кода, ненужное влияние на производительность или даже порождение нового антипаттерна.
Все это важно учитывать, когда вы думаете о применении паттерна проектирования в нашем коде. Мы рассмотрим некоторые паттерны проектирования в JS, с которыми должен быть знаком каждый опытный разработчик JavaScript.
Шаблон конструктора
Когда речь идет о классических объектно-ориентированных языках, конструктор — это специальная функция в классе, которая инициализирует объект с набором значений по умолчанию и/или переданными значениями.
Обычно в JavaScript объекты создаются следующими тремя способами:
После создания объекта существует четыре способа (начиная с ES3) добавить свойства в эти объекты. Вот они:
Наиболее популярный способ создания объектов — это использование фигурных скобок, а для добавления свойств — точечная нотация или квадратные скобки. Любой, кто имеет опыт работы с JavaScript, использовал их.
Мы ранее упоминали, что JavaScript не поддерживает нативные классы, но поддерживает конструкторы через использование ключевого слова new, добавляемого перед вызовом функции. Таким образом, мы можем использовать функцию в качестве конструктора и инициализировать её свойства так же, как мы это делаем в классических языках.
Однако здесь есть пространство для улучшений. Как я уже упоминал ранее, JavaScript использует наследование на основе прототипов. Проблема с предыдущим подходом заключается в том, что метод writesCode переопределяется для каждого экземпляра конструктора Person. Мы можем избежать этого, задав метод в прототип функции:
Теперь оба экземпляра конструктора Person могут получить доступ к общей версии метода writesCode().
Модульный паттерн
Что касается особенностей JavaScript, он никогда не перестаёт удивлять. Ещё одна интересная особенность JavaScript (по крайней мере, с точки зрения объектно-ориентированных языков) заключается в том, что JavaScript не поддерживает модификаторы доступа. В классическом объектно-ориентированном языке пользователь определяет класс и задаёт права доступа для его членов. Поскольку в JavaScript в его обычной форме отсутствуют как классы, так и модификаторы доступа, разработчики JavaScript придумали способ имитировать это поведение при необходимости.
Прежде чем углубиться в специфику модульного паттерна, давайте обсудим концепцию замыкания. Замыкание — это функция, которая имеет доступ к области видимости родительской функции, даже после её завершения. Замыкания помогают нам имитировать поведение модификаторов доступа через области видимости. Покажем это на примере:
Как видите, с помощью IIFE (немедленно вызываемого функционального выражения) мы привязали переменную counter к функции, которая была вызвана и завершилась, но по-прежнему доступна дочерней функции, которая её увеличивает. Так как мы не можем получить доступ к переменной counter извне функционального выражения, мы сделали её приватной через манипуляцию с областью видимости.
Используя замыкания, мы можем создавать объекты с приватными и публичными частями. Эти объекты называются модулями и очень полезны, когда мы хотим скрыть некоторые части объекта и открыть только интерфейс для его использования. Покажем это на примере:
Самое полезное, что вводит этот паттерн, — это чёткое разделение приватных и публичных частей объекта, что очень похоже на концепцию для разработчиков с классическим объектно-ориентированным опытом.
Однако, не всё так идеально. Если вы захотите изменить видимость какого-либо члена, вам придётся модифицировать код везде, где вы использовали этот член, из-за различий в способах доступа к публичным и приватным частям. Кроме того, методы, добавленные к объекту после его создания, не могут получить доступ к приватным членам объекта.
Раскрывающий модульный шаблон
Этот шаблон является улучшением модульного шаблона, как показано выше. Главное отличие состоит в том, что вся логика объекта пишется в приватной области модуля, а затем мы просто открываем те части, которые хотим сделать публичными, возвращая анонимный объект. Также можно изменить имена приватных членов при их сопоставлении с публичными членами.
Раскрывающий модульный шаблон — это один из как минимум трёх способов реализации модульного шаблона. Основные различия между раскрывающим модульным шаблоном и другими вариантами заключаются в том, как ссылаются на публичные члены. В результате раскрывающий модульный шаблон легче использовать и изменять, однако он может быть хрупким в определённых сценариях, таких как использование объектов RMP в качестве прототипов в цепочке наследования. Проблемные ситуации следующие:
Если у нас есть приватная функция, которая ссылается на публичную функцию, мы не можем переопределить публичную функцию, так как приватная функция будет продолжать ссылаться на приватную реализацию, что может привести к ошибке в системе.
Если публичный член ссылается на приватную переменную, и мы пытаемся переопределить публичный член извне модуля, другие функции всё равно будут ссылаться на приватное значение переменной, что также может привести к ошибке в системе.
Шаблон синглтона
Шаблон синглтона используется в сценариях, когда нам требуется ровно один экземпляр класса. Например, если нам нужен объект, содержащий конфигурацию для чего-либо. В таких случаях не обязательно создавать новый объект каждый раз, когда в системе требуется конфигурация.
Как видно из примера, случайное число генерируется один раз, так же как и переданные значения конфигурации.
Важно отметить, что точка доступа для получения значения синглтона должна быть только одна и хорошо известная. Недостатком этого шаблона является то, что его сложно тестировать.
Паттерн посредника
Мы кратко рассмотрим паттерн, который также очень полезен, когда речь идет о разрозненных системах. Когда у нас есть сценарий, в котором несколько частей системы должны взаимодействовать и быть скоординированными, возможно, хорошим решением будет внедрение посредника.
Посредник - это объект, который используется в качестве центральной точки для связи между разрозненными частями системы и управляет рабочим процессом между ними. Важно подчеркнуть, что он управляет рабочим процессом. Почему это важно?
Потому что здесь есть большое сходство с шаблоном издатель/подписчик. Вы можете спросить себя: хорошо, эти два паттерна помогают реализовать лучшую связь между объектами... В чем же разница?
Разница в том, что посредник управляет рабочим процессом, в то время как издатель/подписчик использует так называемый тип связи «отдать и забыть». Издатель/подписчик - это просто агрегатор событий, то есть он просто заботится о том, чтобы запускать события и сообщать нужным подписчикам, какие события были запущены. Агрегатор событий не заботится о том, что происходит после того, как событие было отработано, чего нельзя сказать о медиаторе.
Хорошим примером посредника является интерфейс типа wizard. Допустим, у вас есть большой процесс регистрации для системы, над которой вы работали. Часто, когда от пользователя требуется много информации, рекомендуется разбить его на несколько этапов.
Таким образом, код будет намного чище (его будет легче поддерживать), а пользователь не будет перегружен количеством информации, которая запрашивается только для того, чтобы завершить регистрацию. Посредник - это объект, который будет обрабатывать шаги регистрации, принимая во внимание различные возможные рабочие процессы, которые могут произойти из-за того, что у каждого пользователя потенциально может быть уникальный процесс регистрации.
Очевидным преимуществом этого паттерна проектирования является улучшение взаимодействия между различными частями системы, которые теперь взаимодействуют через посредника и более чистую кодовую базу.
Недостатком является то, что теперь мы ввели единую точку отказа в нашу систему, то есть если наш посредник выйдет из строя, вся система может перестать работать.
Шаблон фасада
Он используется, когда мы хотим создать абстрактный слой между тем, что представлено публично, и тем, что реализовано за кулисами. Он применяется, когда требуется более простой или удобный интерфейс для работы с подлежащим объектом.
Отличный пример этого шаблона можно найти в селекторах библиотек для манипуляции DOM, таких как jQuery, Dojo или D3. Возможно, вы замечали, что эти библиотеки обладают очень мощными функциями селектора; можно писать сложные запросы, например:
Это значительно упрощает работу с выборками, и, хотя на первый взгляд это кажется простым, за этим скрывается сложная логика, которая реализована "под капотом".
Также нужно учитывать компромисс между производительностью и простотой. Желательно избегать излишней сложности, если она не приносит достаточной пользы. В случае упомянутых библиотек этот компромисс оправдан, так как все они очень успешны.
Следующие шаги
Шаблоны проектирования — это очень полезный инструмент, который любой опытный разработчик JavaScript должен знать. Знание особенностей шаблонов проектирования может быть чрезвычайно полезным и сэкономить много времени на протяжении всего жизненного цикла проекта, особенно на этапе поддержки. Изменение и поддержка систем, разработанных с помощью шаблонов проектирования, которые хорошо подходят для нужд системы, может оказаться бесценным.
В этой статье мы рассмотрим механизмы масштабируемости BGP и связанные с ними концепции.
Предыдущие статьи цикла про BGP:
Основы протокола BGP
Построение маршрута протоколом BGP
Формирование соседства в BGP
Оповещения NLRI и политики маршрутизации BGP
Видео: Основы BGP за 7 минут
Механизмы масштабируемости BGP
Истощение доступных автономных системных номеров явилось проблемой точно так же, как было проблемой для интернета истощение IP-адресов. Чтобы решить эту проблему, инженеры обратились к знакомому решению. Они обозначили диапазон номеров AS только для частного использования. Это позволяет вам экспериментировать с AS конструкцией и политикой, например, в лаборатории и использовать числа, которые гарантированно не конфликтуют с интернет-системами.
Помните, что число AS-это 16-разрядное число, допускающее до 65 536 чисел AS. Диапазон для частного использования: 64512-65535.
Еще одним решением проблемы дефицита, стало расширение адресного пространства имен. Было утверждено пространство, представляющее собой 32-разрядное число.
В течение длительного времени, с точки зрения масштабируемости, одноранговые группы Border Gateway Protocol считались абсолютной необходимостью. Мы настраивали одноранговые группы для уменьшения конфигурационных файлов. Так же мы настраивали одноранговые группы для повышения производительности.
Преимущества производительности были нивелированы с помощью значительно улучшенных механизмов, сейчас. Несмотря на это, многие организации все еще используют одноранговые группы, поскольку они поняты и легки в настройке.
Появились в BGP одноранговые группы для решения нелепой проблемы избыточности в BGP конфигурации. Рассмотрим простой (и очень маленький) пример 1. Даже этот простой пример отображает большое количество избыточной конфигурации.
Пример 1: типичная конфигурация BGP без одноранговых групп
ATL1(config)#router bgp 200
ATL1( config-router)#neiqhbor 10.30.30.5 remote-as 200
ATL1( config-router)#neiqhbor 10.30.30.5 update- source lo0
ATL1( config= router)#neiqhbor 10.30 .30.5 password S34Dfr112s1WP
ATL1(config-router)#neiqhbor 10.40.40.4 remote-as 200
ATL1( config-router)#neiqhbor 10.40.40 .4 update- source lo0
ATL1(config-router)#neiqhbor 10.40.40.4 password S34Dfr112s1WP
Очевидно, что все команды настройки относятся к конкретному соседу. И многие из ваших соседей будут иметь те же самые характеристики. Имеет смысл сгруппировать их настройки в одноранговую группу. Пример 2 показывает, как можно настроить и использовать одноранговую группу BGP.
Пример 2: одноранговые группы BGP
ATL2 (config)#router bgp 200
ATL2 (config-router)#neighbor MYPEERGR1 peer-group
ATL2 (config-router)#neighbor MYPEERGR1 remote-as 200
ATL2 (config-router)#neighbor MYPEERG1l update-source lo0
ATL2(config-router)#neighbor MYPEERGRl next-hop-self
ATL2 (config-router)#neighbor 10.40.40 .4 peer-group MYPEERGR1
ATL2 (config-router)#neighbor 10.50.50 .5 peer-group MYPEERGR1
Имейте в виду, что, если у вас есть определенные настройки для конкретного соседа, вы все равно можете ввести их в конфигурацию, и они будут применяться в дополнение к настройкам одноранговой группы.
Почему же так часто использовались одноранговые группы? Они улучшали производительность. Собственно говоря, это и было первоначальной причиной их создания.
Более современный (и более эффективный) подход заключается в использовании шаблонов сеансов для сокращения конфигураций. А с точки зрения повышения производительности теперь у нас есть (начиная с iOS 12 и более поздних версий) динамические группы обновлений. Они обеспечивают повышение производительности без необходимости настраивать что-либо в отношении одноранговых групп или шаблонов.
Когда вы изучаете одноранговую группу, вы понимаете, что все это похоже на шаблон для настроек. И это позволит вам использовать параметры сеанса, а также параметры политики. Что ж, новая и усовершенствованная методология разделяет эти функциональные возможности на шаблоны сессий и шаблоны политики.
Благодаря шаблонам сеансов и шаблонам политик мы настраиваем параметры, необходимые для правильной установки сеанса, и помещаем эти параметры в шаблон сеанса. Те параметры, которые связаны с действиями политик, мы помещаем в шаблон политики.
Одна из замечательных вещей в использовании этих шаблонов сеансов или политик, а также того и другого, заключается в том, что они следуют модели наследования. У вас может быть шаблон сеанса, который выполняет определенные действия с сеансом. Затем вы можете настроить прямое наследование так, чтобы при создании другого наследования оно включало в себя вещи, созданные ранее. Эта модель наследования дает нам большую гибкость, и мы можем создать действительно хорошие масштабируемые проекты для реализаций BGP.
Вы можете использовать шаблоны или одноранговые группы, но это будет взаимоисключающий выбор. Так что определитесь со своим подходом заранее. Вы должны заранее определиться, что использовать: использовать ли устаревший подход одноранговых групп или же использовать подход шаблонов сеанса и политики. После выбора подхода придерживайтесь его, так как, использовать оба подхода одновременно нельзя.
Теперь можно предположить, что конфигурация для шаблонов сеансов будет довольно простой, и это так. Помните, прежде всего, все что мы делаем здесь и сейчас, относится к конкретной сессии. Поэтому, если мы хотим установить timers, нам нужно установить remote-as – и это будет считается параметром сеанса.
Например, мы делаем update source. Мы настраиваем eBGP multihop. Все это имеет отношение к текущему сеансу, и именно это мы будем прописывать в шаблоне сеанса. Обратите внимание, что мы начинаем с создания шаблона. Поэтому используем команду template peer-session, а затем зададим ему имя. И тогда в режиме конфигурации шаблона можем настроить наследование, которое позволит наследовать настройки от другого однорангового сеанса. Можем установить наш remote-as как и/или update source. После завершения, мы используем команду exit-peer-session, чтобы выйти из режима конфигурации для этого сеанса. Пример 3 показывает конфигурацию шаблона сеанса.
Пример 3: Шаблоны сеансов BGP
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL2 (config)#router bgp 200
ATL2 (config-router)#template peer- session MYNAME
ATL2 (config-router-stmp)#inherit peer- session MYOTHERNAME
ATL2 (config- router-stmp )#remote-as 200
ATL2(config-router-stmp )#password MySecrectPass123
ATL2 (config-router-stmp )#exit-peer-session
ATL2 (config-router)#neiqhbor 10.30.30 .10 inherit peer-session MYNAME
ATL2 (config-router)#end
ATL2#
Это простой пример настройки соседства с помощью оператора neighbor и использования наследования однорангового сеанса. Затем присваивается имя однорангового сеанса, созданного нами для нашего шаблона сеанса. Это соседство наследует параметры сеанса.
Помните, что, если вы хотите сделать дополнительную настройку соседства, можно просто присвоить соседу IP-адрес, а затем выполнить любые настройки вне шаблона однорангового сеанса, которые вы хотите дать этому соседу. Таким образом, у вас есть та же гибкость, которую мы видели с одноранговыми группами, где вы можете настроить индивидуальные параметры для этого конкретного соседа вне шаблонного подхода этого соседства.
Вы можете подумать, что шаблоны политик будут иметь сходную конструкцию и использование с шаблонами сеансов, и вы будете правы. Помните, что если ваши шаблоны сеансов находятся там, где мы собираемся настроить параметры, которые будут относиться к сеансу BGP, то, конечно, шаблоны политик будут храниться там, где мы храним параметры, которые будут применяться к политике.
Пример 4 показывает настройку и использование шаблона политики BGP.
Пример 4: Шаблоны политики BGP
ATL2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ATL2 (config)#router bgp 200
ATL2(config-router)#template peer-policy MYPOLICYNAME
ATL2 (config-router-ptmp )#next-hop-self
ATL2 (config-router-ptmp )#route-map MYMAP out
ATL2 (config-router-ptmp )#allowas-in
ATL2 (config-router-ptmp )#exit-peer-policy
ATL2 (config-router)#neighbor 10.40.40.10 remote-as 200
ATL2 (config-router)#neighbor 10.40.40.10 inherit peer-policy MYNAME
ATL2 (config-router)#end
ATL2#
Да, все эти параметры, которые мы обсуждали при изучении манипуляций с политикой, будут тем, что мы будем делать внутри шаблона политики. Однако одним из ключевых отличий между нашим шаблоном политики и шаблоном сеанса является тот факт, что наследование здесь будет еще более гибким.
Например, мы можем перейти к семи различным шаблонам, от которых мы можем непосредственно наследовать политику. Это дает нам еще более мощные возможности наследования с помощью шаблонов политик по сравнению с шаблонами сеансов.
Опять же, если мы хотим сделать независимые индивидуальные настройки политики для конкретного соседа, мы можем сделать это, добавив соответствующие команды соседства.
Благодаря предотвращению циклов и правилу разделения горизонта (split-horizon rule) IBGP, среди прочих факторов, нам нужно придумать определенные решения масштабируемости для пирингов IBGP. Одним из таких решений является router reflector.
Рис. 1: Пример топологии router reflector
Конфигурация router reflector удивительно проста, поскольку все это обрабатывается на самом router reflector (R3). Клиенты route reflector – это R4, R5 и R6. Они совершенно не знают о конфигурации и настроены для пиринга IBGP с R3 как обычно. Пример 5 показывает пример конфигурации router reflector. Обратите внимание, что это происходит через простую спецификацию клиента router reflector.
Пример 5: BGP ROUTE REFLECTOR
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3 (config)#router bgp 200
R3 (config-router)#neighbor 10.50.50.10 remote -as 200
R3 (config-router)#neighbor 10.50.50.10 route-reflector-client
R3 (config-router)#end
R3#
Route reflector автоматически создает значение идентификатора (ID) кластера для кластера, и это устройство и эти клиенты будут частью того, что мы называем кластером route reflector. Cisco рекомендует разрешить автоматическое назначение идентификатора кластера для идентификации клиента. Это 32-разрядный идентификатор, который BGP извлекает из route reflector.
Магия Route reflector заключается в том, как меняются правила IBGP. Например, если обновление поступает от клиента Route reflector (скажем, R4), то устройство R3 «отражает» это обновление своим другим клиентам (R5 и R6), а также своим неклиентам (R1 и R2). Это обновление происходит даже при том, что конфигурация для IBGP значительно короче полной сетки пирингов, которая обычно требуется.
А теперь что будет, если обновление поступит от не клиента Route reflector (R1)? Route reflector отправит это обновление всем своим клиентам Route reflector (R4, R5 и R6). Но тогда R3 будет следовать правилам IBGP, и в этом случае он не будет отправлять обновление через IBGP другому не клиенту Route reflector (R2).
Чтобы решить эту проблему, необходимо будет создать пиринг от R1 к устройству R2 с помощью IBGP. Или, можно добавить R2 в качестве клиента Route reflector R3.
Есть еще один способ, которым мы могли бы решить проблему с масштабируемостью IBGP- это манипулирование поведением EBGP. Мы делаем это с конфедерациями. Вы просто не замечаете, что конфедерации используются так же часто, как Route reflector. И причина состоит в том, что они усложняют нашу топологию, и делают поиск неисправностей более сложным. На рис. 2 показан пример топологии конфедерации.
Рисунок 2: Пример топологии конфедерации
Мы имеем наш AS 100. Для создания конфедерации необходимо создать небольшие субавтономные системы внутри нашей основной автономной системы. Мы их пронумеруем с помощью, номеров автономных систем только для частного использования.
Что мы имеем, когда манипулируем поведением eBGP, что бы имеет конфедерацию EBGP пирингов? Это позволяет нам установить пиринги между соответствующими устройствами, которые хотим использовать в этих автономных системах. Как вы можете догадаться, они не будут следовать тем же правилам, что и наши стандартные пиринги EBGP. Еще один важный момент заключается в том, что все это для внешнего неконфедеративного мира выглядит просто как единый AS 100.
Внутри мы видим реальные AS, и конфедеративные отношения EBGP между ними. Помимо устранения проблемы разделения горизонта IBGP, что же меняется с пирингами конфедерации EBGP? В следующем прыжке поведение должно измениться. Следующий прыжок не меняется тогда, когда мы переходим от одной из этих небольших конфедераций внутри нашей АС к другой конфедерации.
Вновь добавленные атрибуты обеспечивают защиту от цикла из-за конфедерации. Атрибут AS_confed_sequence и AS_confed_set используются в качестве механизмов предотвращения циклов.
Пример 6 показывает пример частичной настройки конфедерации BGP.
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3 (config)#router bgp 65501
R3(config-router)#bgp confederation identifier 100
R3 (config-router)#bgp confederation peers 65502
R3 (config-router)#neighbor 10 .20.20.1 remote-as 65502
R3 (config-router)#end
R3#
Иногда возникает необходимость применения общих политик к большой группе префиксов. Это делается легко, если вы помечаете префиксы специальным значением атрибута, называемым сообществом (community). Обратите внимание, что сами по себе атрибуты сообщества ничего не делают с префиксами, кроме как прикрепляют значение идентификатора. Это 32-разрядные значения (по умолчанию), которые мы можем именовать, чтобы использовать дополнительное значение.
Вы можете настроить значения сообщества таким образом, чтобы они были значимы только для вас или значимы для набора AS. Вы также можете иметь префикс, который содержит несколько значений атрибутов сообщества. Кроме того, можно легко добавлять, изменять или удалять значения сообщества по мере необходимости в вашей топологии BGP.
Атрибуты сообщества могут быть представлены в нескольких форматах. Более старый формат выглядит следующим образом:
Decimal - 0 to 4294967200 (в десятичном)
Hexadecimal – 0x0 to 0xffffffa0 (в шестнадцатеричном)
Более новый формат:
AA:NN
AA - это 16-битное число, которое представляет ваш номер AS, а затем идет 16-битное число, используемое для задания значимости своей политике AS. Таким образом, вы можете задать для AS 100 100:101, где 101- это номер внутренней политики, которую вы хотите применить к префиксам.
Есть также хорошо известные общественные значения. Это:
No-export - префиксы не объявляются за пределами AS. Вы можете установить это значение, когда отправляете префикс в соседний AS. чтобы заставить его (соседний AS) не объявлять префикс за собственные границы.
Local-AS - префиксы с этим атрибутом сообщества никогда не объявляются за пределами локального AS
No-advertise - префиксы с этим атрибутом сообщества не объявляются ни на одном устройстве
Эти хорошо известные атрибуты сообщества просто идентифицируются по их зарезервированным именам.
Есть также расширенные сообщества, которые также можно использовать. Они предлагают 64-битную версию для идентификации сообществ! Задание параметров осуществляется настройкой TYPE:VALUE. Выглядит оно следующим образом:
65535:4294967295
Как вы можете догадаться, мы устанавливаем значения сообщества, используя route maps. Пример 7 показывает пример настроек. Обратите внимание, что в этом примере также используется список префиксов. Они часто используются в BGP для гибкой идентификации многих префиксов. Они гораздо более гибки, чем списки доступа для этой цели.
Пример 7: Установка значений сообщества в BGP
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#ip prefix-list MYLIST permit 172.16.0.0/16 le 32
R3(config)#route-map SETCOMM permit 10
R3(config-route-map)#match ip address prefix-list MYLIST
R3(config-route-map)#set community no-export
R3(config-route-map)#route-map SETCOMM permit 20
R3(config)#router bgp 100
R3(config-router)#neighbor 10.20.20.1 route-map SETCOMM out
R3 (config-router)#neighbor 10.20.20.1 send-community
R3(config-router)#end
R3#