По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Давайте рассмотрим один пример настройки DHCPv6:
В этом примере у нас есть DHCP-клиент, маршрутизатор и DHCP-сервер. Поскольку DHCP-клиент и DHCP-сервер не находятся в одной подсети, нам придется настроить маршрутизатор для ретрансляции сообщений DHCP.
Поиск клиентом IPv6 адреса будет начинаться с сообщения запроса:
Клиент будет использовать свой link-local адрес в качестве источника, а адрес назначения будет многоадресный адрес FF02:: 1:2 (all-DHCP-agents). Это link-local multicast адрес, поэтому он не будет покидать подсеть. В результате DHCP-сервер никогда не получит это сообщение запроса.
На маршрутизаторе мы настроим ретрансляцию DHCP таким образом, чтобы запрашивающее сообщение было переадресовано на DHCP-сервер:
Router(config)#interface fa0/0
Router(config-if)#ipv6 dhcp relay destination 2001:5:6:7::2
Это гарантирует, что маршрутизатор пересылает сообщения DHCP между клиентом и DHCP-сервером. Вот как это выглядит:
Маршрутизатор переадресует сообщение запроса, и адрес будет изменнен. Источником будет IPv6-адрес на интерфейсе Fa1/0 нашего маршрутизатора, а местом назначения-IPv6-адрес DHCP-сервера. Это большая разница по сравнению с DHCP relay для IPv4, где был бы использован IP-адрес на Fa0/0.
Другие сообщения DHCP будут использовать те же адреса. Между маршрутизатором и DHCP-сервером мы будем использовать 2001:5:6:7::1 и еще 2001:5:6:7::2 адреса. Маршрутизатор будет перенаправлять трафик на DHCP-клиент, используя его link-local адрес и в качестве места назначения.
Вторая часть тут
Пересечение многочисленных дискуссий в мире сетевого инжиниринга, было одной из проблем, которая затрудняла принятие решения о том, является ли коммутация пакетов или каналов лучшим решением. Как следует вычислять loop-free пути в сети с коммутацией пакетов?
Поскольку сети с коммутацией пакетов на протяжении всей истории сетевой инженерии ассоциировались с распределенными плоскостями управления (control plane), а сети с коммутацией каналов -с централизованными плоскостями управления (control plane), проблема эффективного вычисления безцикловых (loop-free) путей оказала значительное влияние на принятие решения о том, являются ли сети с коммутацией пакетов жизнеспособными или нет.
На заре сетевой инженерии доступная вычислительная мощность, память и пропускная способность часто были в дефиците.
В 1984 году, когда происходили в основном своем эти дискуссии, любая разница в объеме процессора и памяти между двумя способами расчета безцикловых путей через сеть оказала бы существенное влияние на стоимость построения сети. Когда пропускная способность имеет первостепенное значение, уменьшение количества битов, требуемых плоскостью управления (control plane) для передачи информации, необходимой для вычисления набора loop-free путей через сеть, создает реальную разницу в объеме пользовательского трафика, который может обрабатывать сеть. Уменьшение количества битов, необходимых для работы элемента управления, также вносит большую разницу в стабильность сети при более низких полосах пропускания.
Например, использование формата Type Length Vector (TLV) для описания информации о плоскости управления (control plane), передаваемой по сети, добавляет несколько октетов информации к общей длине пакета-но в контексте канала 2 Мбит / с, усугубленного chatty control plane, затраты могут значительно перевесить долгосрочное преимущество расширяемости протокола.
Протокольные войны в некоторых моментах были довольно жаркими. Были организованы целые исследовательские проекты и написаны статьи о том, почему и как один протокол лучше другого.
Было предложено большое разнообразие механизмов для решения задач вычисления loop-free путей через сеть. В конечном счете были широко развернуты и использованы три общих класса решений:
Distance Vector protocols (протоколы вектора расстояния), которые вычисляют свободные от петель пути hop by hop на основе стоимости пути.
Link State protocols (протоколы состояния связи), которые вычисляют свободные от петель пути через базу данных, синхронизированную между сетевыми устройствами.
Path Vector protocols (протоколы вектора пути), которые вычисляют свободные от петель пути hop by hop на основе записи предыдущих прыжков.
Дискуссия о том, какой протокол лучше всего подходит для каждой конкретной сети и по каким конкретным причинам, все еще продолжается. И это, возможно, бесконечный спор, поскольку нет окончательного ответа на этот вопрос. Возможно, как и при подгонке сети под бизнес, всегда будет какая-то степень искусства, связанная с тем, чтобы заставить конкретную плоскость управления (control plane) работать в конкретной сети. Однако большая часть актуальности этого вопроса была вызвана ростом скорости сетей-вычислительной мощности, памяти и пропускной способности.
Четвертую часть цикла статей про QoS можно почитать по ссылке.
Представим себе следующую задачу: необходимо сделать так, чтобы при входящем звонке клиент слышал музыку в трубке и одновременно с этим звонил телефон у секретаря. Допустим, что у нас нет IVR и мы просто хотим заменить скучные гудки на какую-нибудь приятную музыку пока клиенту кто-нибудь не ответит.
Сделать это очень просто. Бежим в модуль Ring Group, закидываем туда нужные внутренние номера и в разделе Play Music On Hold и вместо категории Ring, которая и отправляет в трубку звонящего эти самые скучные гудки, ставим туда какую-нибудь приятную музыку, предварительно добавив новую категорию в модуле Music On Hold. Осталось только поставить новую ринг-группу на входящий маршрут и всё готово. Предельно просто.
Сценарий №2
Что если мы хотим сообщить звонящему какую-либо информацию прежде чем он услышит музыку (пойдет вызов на секретаря)? Например, поприветствовать, сообщить имя своей компании и поблагодарить за звонок. Для этого всё в том же модуле Ring Group нужно поставить предварительно записанное сообщение в поле Announcement. Теперь, позвонив в нашу компанию, клиент услышит приветствие, а затем приятную музыку на ожидании, пока ему не ответит секретарь. Нужно отметить, что телефон у секретаря зазвонит только тогда, когда начнёт играть музыка на ожидании, пока проигрывается приветствие из опции Announcement, телефон секретаря будет молчать.
Сценарий №3
Допустим, что речь диктора, записанная в нашем приветствии звучит 7 секунд, а для принятия звонка секретарю требуется в среднем 2 секунды. Мы хотим повысить вероятность того, что как только клиент прослушает приветствие, на его звонок сразу же ответят. Согласитесь, оперативность ответа на звонок создаёт у звонящего положительное впечатление о компании. Таким образом, нам нужно как-то задержать момент, когда у секретаря зазвонит телефон где-то на 5 секунд, в то время как звонящий будет слушать текст нашего приветствия. То есть, идеальный сценарий, которого мы хотим добиться следующий:
Клиент позвонил в нашу компанию;
Клиент слушает наше приветствие (7 секунд);
На 5 секунде приветствия, у секретаря начинает звонить телефон;
Через примерно 2 секунды, он принимает звонок и начинает общаться с клиентом;
Иными словами, нам нужна некая "буферная зона", в которой будут звучать первые 5 секунд нашего приветствия, а на 2 последних секундах у секретаря звонил телефон.
Сразу стоит оговориться, что стандартными средствами модулей Ring Group, Inbound Route и Announcement эту задачу решить нельзя. Но в этой статье мы покажем способ, который поможет вам эффективно управлять задержкой отправки сигнала вызова на телефоны, пока звонящий слушает приветствие.
Итак, первая хитрость которой мы воспользуемся – это создание звукового файла, в котором речь приветствия и музыка будут звучать друг за другом. То есть, один звуковой файл – сначала текст приветствия, а затем музыка на ожидании, например, в течении 5 минут. Этот файл нужно добавить в новую категорию в модуле Music On Hold
А теперь, к созданию той самой "буферной зоны", в которой будут звучат первые 5 секунд нашего звукового файла. Для этого, в модуле Extension нужно создать виртуальный внутренний номер Virtual Extension. Виртуальный внутренний номер – это номер на нашей IP-АТС, который не требует какой-либо регистрации на конечном устройстве (будь то стационарный телефон или просто софтфон), при его создании, система не запрашивает и не создаёт никакого пароля Secret
А теперь самое главное – включаем и редактируем правила Follow Me для нашего виртуального внутреннего номера следующим образом.
Здесь самыми важными параметрами являются:
Initial Ring Time - время, в течение которого, звонок будет идти на этот номер, прежде чем уйдёт на номера из списка Follow-Me List . Это и есть те самые 5 секунд, на которые нам нужно задержать момент, когда у секретаря зазвонит телефон.
Follow-Me List - номер, на который уйдёт звонок после времени, указанном в Initial Ring Time. В нашем примере, 1011 – это номер секретаря.
Play Music On Hold - звуковой файл, содержащий приветствие и музыку на удержании.
Можно выбрать любую стратегию обзвона типа ringall и её модификации. Теперь этот виртуальный внутренний номер можно повесить на входящий маршрут.