По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
До сих пор в этой серии статей примеры перераспределения маршрутов, над которыми мы работали, использовали один роутер, выполняющий перераспределение между нашими автономными системами. Однако с точки зрения проекта, глядя на этот роутер понимаем, что это единственная уязвимая точка, то есть точка отказа.
Для избыточности давайте подумаем о добавлении второго роутера для перераспределения между несколькими автономными системами. То, что мы, вероятно, не хотим, чтобы маршрут объявлялся, скажем, из AS1 в AS2, а затем AS2 объявлял тот же самый маршрут обратно в AS1, как показано на рисунке.
Хорошая новость заключается в том, что с настройками по умолчанию, скорее всего не будет проблем. Например, на приведенном выше рисунке роутер CTR2 узнал бы два способа добраться до Сети A. Один из способов — это через OSPF, к которому он подключен. Другой путь был бы через EIGRP AS, через роутер CTR1 и обратно в OSPF AS. Обычно, когда роутер знает, как добраться до сети через два протокола маршрутизации, он сравнивает значения административного расстояния (AD) протоколов маршрутизации и доверяет протоколу маршрутизации с более низким AD. В этом примере, хотя EIGRP AD обычно составляет 90, что более правдоподобно, чем OSPF AD 110, AD EIGRP External route (т. е. маршрута, который возник в другом AS) составляет 170. В результате OSPF-изученный маршрут CTR2 к сети A имеет более низкую AD (т. е. 110), чем AD (т. е. 170) EIGRP-изученного маршрута к сети A. Что в итоге? CTR2 отправляет трафик в Сеть A, отправляя этот трафик в OSPF AS, без необходимости передавать EIGRP AS.
Время от времени, однако, нам потребуется произвести настройки некоторых не дефолтных параметров AD, или же нам понадобятся creative metrics, применяемые к перераспределенным маршрутам. В таких случаях мы подвергаемся риску развития событий, описанных на предыдущем рисунке.
Давайте обсудим, как бороться с такой проблемой. Рассмотрим следующую топологию.
В этой топологии у нас есть две автономные системы, одна из которых работает под управлением OSPF, а другая- под управлением EIGRP. Роутеры CTR1 и CTR2 в настоящее время настроены для выполнения взаимного перераспределения маршрутов между OSPF и EIGRP. Давайте взглянем на таблицы IP-маршрутизации этих магистральных роутеров.
Обратите внимание, в приведенном выше примере, что с точки зрения роутера CTR2, лучший способ добраться до Сети 192.0.2.0 / 30 — это next-hop на следующий IP-адрес 192.0.2.5 (который является роутером OFF1). Это означает, что если бы роутер CTR2 хотел отправить трафик в сеть 192.0.2.0 /30, то этот трафик остался бы в пределах OSPF AS. Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в Интересно, что процесс маршрутизации EIGRP, запущенный на роутере CTR2, также знает, как добраться до Сети 192.0.2.0 / 30 из-за того, что роутер CTR1 перераспределяет этот маршрут в EIGRP AS, но этот маршрут считается EIGRP External route. Поскольку EIGRP External route AD 170 больше, чем OSPF AD 110, в OSPF маршрут прописывается в таблице IP-маршрутизации роутера CTR2.
Именно так обычно работает Route redistribution, когда у нас есть несколько роутеров, выполняющих перераспределение маршрутов между двумя автономными системами. Однако, что мы можем сделать, если что-то идет не так, как ожидалось (или как мы хотели)? Как мы можем предотвратить перераспределение маршрута, перераспределенного в AS, из этого AS и обратно в исходное AS, например, в примере, показанном на следующем рисунке.
В приведенном выше примере роутер OFF1 объявляет сеть 192.168.1.0 / 24 роутеру CTR1, который перераспределяет этот маршрут из AS1 в AS2. Роутер OFF2 получает объявление маршрута от роутера CTR1 и отправляет объявление для этого маршрута вниз к роутеру CTR2. Роутер CTR2 затем берет этот недавно изученный маршрут и перераспределяет его от AS2 к AS1, откуда он пришел. Мы, скорее всего, не хотим, чтобы это произошло, потому что это создает неоптимальный маршрут.
Общий подход к решению такой проблемы заключается в использовании route map в сочетании с tag (тегом). В частности, когда маршрут перераспределяется из одного AS в другой, мы можем установить тег на этом маршруте. Затем мы можем настроить все роутеры, выполняющие перераспределение, чтобы блокировать маршрут с этим тегом от перераспределения обратно в его исходный AS, как показано на следующем рисунке.
Обратите внимание, что в приведенной выше топологии, когда маршрут перераспределяется от AS1 к AS2, он получает тег 10. Кроме того, роутер CTR2 имеет инструкцию (настроенную в карте маршрутов), чтобы не перераспределять любые маршруты из AS2 в AS1, которые имеют тег 10. В результате маршрут, первоначально объявленный роутером OFF1 в AS1, никогда не перераспределяется обратно в AS1, тем самым потенциально избегая неоптимального маршрута.
Далее давайте еще раз рассмотрим, как мы можем настроить этот подход к тегированию, используя следующую топологию. В частности, на роутерах CTR1 и CTR2 давайте установим тег 10 на любом маршруте, перераспределяемом из OSPF в EIGRP. Затем, на тех же самых роутерах, мы предотвратим любой маршрут с тегом 10 от перераспределения из EIGRP обратно в OSPF.
Для начала на роутере CTR1 мы создаем карту маршрутов, целью которой является присвоение тегу значения 10.
CTR1 # conf term
CTR1 (config) # route-map TAG10
CTR1 (config-route-map) # set tag 10
CTR1 (config-route-map) #exit
CTR1 (config) #
Обратите внимание, что мы не указали permit как часть инструкции route-map, и мы не указали порядковый номер. Причина в том, что permit — это действие по умолчанию, и карта маршрута TAG10 имела только одну запись.
Далее мы перейдем к роутеру CTR2 и создадим карту маршрутов, которая предотвратит перераспределение любых маршрутов с тегом 10 в OSPF. Кроме того, мы хотим, чтобы роутер CTR2 маркировал маршруты, которые он перераспределяет из OSPF в EIGRP со значением тега 10. Это означает, что мы хотим, чтобы роутер CTR1 предотвратил перераспределение этих маршрутов (со значением тега 10) обратно в OSPF. Итак, пока мы находимся здесь на роутере CTR1, давайте настроим route-map, которая предотвратит Route redistribution со значением тега 10 в OSPF.
CTR1 (config) # route-map DENYTAG10 deny 10
CTR1 (config-route-map) # match tag 10
CTR1 (config-route-map) # exit
CTR1 (config) # route-map DENYTAG10 permit 20
CTR1 (config-route-map) # end
CTR1 #
Эта недавно созданная route-map (DENYTAG10) использует ключевые слова permit и deny, и у нее есть порядковые номера. Порядковый номер 10 используется для запрещения маршрутов с тегом 10. Затем имеем следующий порядковый номер (который мы пронумеровали 20), чтобы разрешить перераспределение всех других маршрутов.
Теперь, когда мы создали наши две карты маршрутов, давайте применим TAG10 route map к команде EIGRP redistribute (к тегу routes, перераспределяемому в EIGRP со значением 10). Кроме того, мы хотим применить DENYTAG10 route map к команде OSPF redistribute (чтобы предотвратить перераспределение маршрутов, помеченных значением 10, обратно в OSPF AS).
CTR1 # conf term
CTR1 (config) # router eigrp 100
CTR1 (config-router) # redistribute ospf 1 route-map TAG10
CTR1 (config-router) # router ospf 1
CTR1 (config-router) # redistribute eigrp 100 subnets route-map DENYTAG10
CTR1 (config-router) # end
CTR1 #
Теперь нам нужно ввести зеркальную конфигурацию на роутере CTR2.
CTR2#conf term
CTR2(config)#route-map TAG10
CTR2(config-route-map) # set tag 10
CTR2(config-route-map) # exit
CTR2(config)#route-map DENYTAG10 deny 10
CTR2(config-route-map) # match tag 10
CTR2(config-route-map) # exit
CTR2(config) # route-map DENYTAG10 permit 20
CTR2(config-route-map) # exit
CTR2(config) # router eigrp 100
CTR2(config-router) # redistribute ospf 1 route-map TAG10
CTR2(config-router) # router ospf 1
CTR2(config-router) # redistribute eigrp 100 subnets route-map DENYTAG10
CTR2(config-router) # end
CTR2#
Просто чтобы убедиться, что наши маршруты помечены, давайте проверим таблицу топологии EIGRP роутера OFF2.
Обратите внимание, что все маршруты, перераспределенные в EIGRP из OSPF, теперь имеют тег 10, и мы сказали роутерам CTR1 и CTR2 не перераспределять эти маршруты обратно в OSPF. Именно так мы можем решить некоторые потенциальные проблемы, возникающие при перераспределении маршрутов.
Дело за малым - прочитайте нашу статью про route redistribution с помощью IPv6.
В этой статье рассмотрим как решить следующие неисправности:
Вам не удаётся включить виртуальную машину
При включении виртуальной машины происходит сбой
Вы видите ошибку:
An unexpected error was received from the ESX host while powering on VM .
Reason: Cannot open the disk disk_name or one of the snapshot disks it depends on.
Где причина одна из следующего:
Reason: Failed to lock the file.
Reason: The parent virtual disk has been modified since the child was created.
Reason: The destination file system does not support large files.
Reason: Could not open/create change tracking file.
Reason: Cannot allocate memory.
Reason: The file specified is not a virtual disk.
Reason: Insufficient permission to access file.
Решение
Ошибка №1: не удалось заблокировать файл.
Ошибка «не удалось заблокировать файл» означает, что файл открывается другим процессом и используемый Вами процесс не может открыть файл должным образом.
Это обычно происходит, если Вы:
Пытаетесь запустить вторую виртуальную машину, используя тот же .vmx файл конфигурации виртуальной машины.
Включаете виртуальную машину с подключенными дисками с помощью утилиты vmware-mount.
Пытаетесь включить виртуальную машину через пользовательский интерфейс во время операции снимка.
Пытаетесь добавить виртуальный диск к виртуальной машине, которая уже используется.
Ошибка №2: Родительский виртуальный диск был изменен с момента создания дочернего диска
Данная ошибка возникает, когда снимки находятся в плохом состоянии, либо из-за ручного вмешательства, либо из-за сбоя системы.
Ошибка №3: целевая файловая система не поддерживает большие файлы
Данная проблема возникает, если размер блока целевого хранилища данных не поддерживает VMDK такого же размера, как исходный.
Чтобы устранить данную проблему, убедитесь, что целевое хранилище данных отформатировано с размером блока, достаточным для поддержки файла VMDK исходной машины.
Ошибка №4: не удалось открыть или создать файл отслеживания изменений
Эта проблема может возникнуть, если файл filename-ctk.vmdk был создан ранее и не был очищен.
Ошибка №5: не удается выделить память
Данная проблема может возникнуть, если в модуле VMFS не хватает места в куче.
Ошибка №6: указанный файл не является виртуальным диском
Данная проблема может возникнуть, если файл дескриптора .vmdk поврежден или отсутствует. Чтобы решить данную проблему, создайте новый файл дескриптора .vmdk для этого диска, а затем отмените регистрацию и заново зарегистрируйте виртуальную машину. Это гарантирует, что клиент vSphere определит правильный размер диска и виртуальная машина включится правильно.
Ошибка №7: недостаточно прав для доступа к файлу
Данная проблема обычно наблюдается в виртуальных машинах, расположенных на хранилищах данных NFS. Данная проблема может возникнуть из-за проблем с разрешениями в хранилище данных NFS.
Чтобы решить данную проблему, убедитесь, что хост имеет правильные разрешения на чтение / запись для доступа к экспорту NFS. Если в массиве хранения установлен параметр "Нет корневого квадрата" (No Root Squash), убедитесь, что данная опция включена, или обратитесь к администратору хранилища.
В сегодняшней статье расскажем, как организовать функцию прослушивания телефонных разговоров, как входящих, так и исходящих, которые проходят в реальном времени на нашем сервере IP-АТС Asterisk. Для этих целей будем использовать стандартное приложение Asterisk - ChanSpy(). Данная задача часто встречается при организации call-центров, когда есть группа агентов, принимающих или совершающих вызовы и группа супервайзеров, контролирующих их взаимодействие с клиентами КЦ. Для того, чтобы научить агентов грамотно общаться с клиентами, супервайзерам необходимо иметь доступ не только к записям разговоров агентов, но и к разговорам в реальном времени, в том числе, с возможностью прямо во время разговора подсказать агенту какую-либо информацию и не быть услышанным клиентом. Здесь то нам и приходит на помощь ChanSpy – своеобразный “шпионский” канал.
Работа в FreePBX
По умолчанию, данная функция доступна в графической оболочке FreePBX по средствам набора специального кода Feature Code Feature Code, а именно -комбинации цифр 555
То есть, мы можем, набрав 555, подключиться к случайному разговору, который в настоящий момент проходит на IP-АТС и прослушивать его. Если разговоров несколько, то переключаться между ними можно с помощью *. Согласитесь, это слегка неудобно. Вдруг нам нужен конкретный агент, который в настоящий момент разговаривает с конкретным клиентом? Не перебирать же все разговоры и пытаться по голосу определить нужного нам агента!
Работа в Asterisk CLI
Чтобы упростить задачу супервайзерам и расширить стандартный функционал ChanSpy на FreePBX, мы немного отредактируем конфигурационные файлы Asterisk.
Для начала давайте обратимся к синтаксису ChanSpy().
ChanSpy([chanprefix,[options]]), где:
chanprefix - специальный префикс канала. Например мы можем указать шаблон для внутренних номеров, разговоры которых мы хотим прослушивать;
options - буквенные обозначения опций с учётом регистра и параметров прослушивания канала. Рассмотрим наиболее полезные:
b – позволяет подключаться к каналам, задействованным в конференц-звонке;
d – позволяет вручную управлять режимом прослушивания канала: 4 – только прослушивание, 5 – только подсказки (шёпот), 6 – и подслушивание и подсказки;
E – отключается от прослушиваемого канала, когда тот кладёт трубку;
q – тихий режим. Не проигрывает никаких звуков, когда происходит подключение к прослушиваемому каналу;
v – позволяет настроить начальный уровень громкости от -4 до 4;
w – позволяет говорить в подслушиваемый канал. Функция подсказок или “шёпота”;
Все остальные опции, доступные в ChanSpy можно узнать из командной строки Asterisk, используя команду:
core show application chanspy
Для того, чтобы настроить новое правило ChanSpy, нужно открыть файл extension_custom.conf, который лежит в /etc/asterisk/ и открыть его любым удобным текстовым редактором, например nano:
nano /etc/asterisk/extension_custom.conf
И внесём туда следующий контекст:
[app-custom-chanspy]
exten => 555.,1,Authenticate(48151623) //48151623 – это пароль для доступа к функционалу прослушивания;
exten => 555.,n,Answer
exten => 555.,n,Wait(1)
exten => 555.,n,ChanSpy(SIP/${EXTEN:3},qw)
exten => 555.,n,Hangup
Давайте разберём что получилось: пользователь, например, супервайзер набирает комбинацию 555115, где 555 – доступ к ChanSpy, а 115 – внутренний номер агента, к разговору которого хочет подключиться супервайзер. При наборе “555” пользователя попросят ввести пароль (в нашем случае 48151623), это поможет ограничить доступ к функционалу прослушивания разговоров на нашей IP-АТС. После подтверждения пароля, пользователю будет доступен функционал прослушивания разговора и “шёпота”, причем при подключении к разговору никаких уведомлений проигрываться не будет, так как включен тихий режим.