По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Работа SR (Segment Routing) в MPLS и SR в IPv6 аналогична во всех отношениях, за исключением того, как передается и обрабатывается стек меток. Заголовки SR в IPv6 переносятся в поле метки потока, показанном на рисунке 8.
В реализации IPv6 SR стек меток SR переносится в заголовке маршрутизации заголовка пакета IPv6. Информация в этом заголовке предназначена специально для предоставления информации об узлах, через которые "этот пакет" должен проходить при маршрутизации по сети, поэтому он служит той же цели, что и стек меток SR. В случае реализации SR IPv6 каждая метка имеет длину 128 бит, поэтому в качестве SID можно использовать некоторый локальный IPv6-адрес.
Один интересный момент заключается в том, что спецификации IPv6 указывают, что заголовок IPv6 не должен изменяться маршрутизатором при обработке пакета (более подробную информацию см. В RFC8200). Вместо того, чтобы выталкивать (pop), проталкивать (push) и менять местами метки, SR IPv6 полагается на то, что каждый узел на пути имеет указатель на текущую метку в обрабатываемом стеке.
Метки маршрутизации сегментов сигнализации
SR технически является механизмом маршрутизации источника, потому что источник выбирает путь через сеть-хотя маршрутизация источника в SR может быть гораздо более свободной, чем традиционная маршрутизация источника. Для каждой метки в стеке существует два возможных способа обработки пакета узлом вдоль пути:
Метка содержит подробные инструкции о том, как пакет должен обрабатываться на этом устройстве: POP или CONTINUE сегмента (метки) и обработать пакет соответствующим образом.
Метка не содержит явных инструкций о том, как пакет должен обрабатываться на этом устройстве: использовать информацию о локальной маршрутизации для пересылки пакета и CONTINUE сегмента.
Ни в том, ни в другом случае узел обработки не должен знать обо всем пути для коммутации пакета: он либо просто следует по указанному пути метки, либо обрабатывает пакет на основе чисто локальной информации. Благодаря этой парадигме передача сигналов SR проста. Необходимы два типа сигнализации.
Локальный узел, префикс и SID смежности, назначенные узлу в сети, должны быть объявлены каждым узлом в сети. Эта передача сигналов в основном осуществляется в протоколов маршрутизации. Например, протокол от промежуточной системы к промежуточной системе (IS-IS) расширен черновым вариантом расширений (Intermediate System to Intermediate System- IS-IS) для Segment Routing1 для переноса SID префиксов с использованием значения длины подтипа (sub-TLV), как показано на рисунке 9.
Также для стандартизации предлагаются расширения к другим протоколам маршрутизации и уровня управления. Поскольку расчет пути в SR основан на источнике, нет необходимости переносить путь в протоколе распределенной маршрутизации. Единственная реальная необходимость - предоставить каждому узлу в сети информацию, необходимую для переноса информации об узле SR, префиксе и смежности.
В случае, когда пути SR вычисляются централизованным устройством или контроллером, должен быть способ объявить путь метки, который будет использоваться для достижения определенного назначения. Были предложены расширения для Border Gateway Protocol (BGP) в политике маршрутизации объявленных сегментов в BGP,2 и в протоколе Path Computation Element Protocol (PCEP) в расширениях PCEP для Segment Routing.3 Эти два вида объявления отделены друг от друга, поскольку единственным узлом в сети, который должен либо вычислить, либо наложить список сегментов, является головной узел туннеля или точка, где трафик входит в путь сегмента.
Желание использовать данные с внешних сервисов это вполне обычная практика. Так как многие из этих сервисов доступны по HTTP(S) (REST API, например), то в этой статье мы хотим показать простой способ обращения к этим сервисам по cURL и обработку данных в случае, если сервер вернет JSON. Все взаимодействия будут выполняться из диалплана.
Простой cURL запрос
В диалплане Asterisk существует функция CURL, которая позволяет получить содержимое WEB или FTP страницы. Синтаксис запроса следующий:
CURL(url,post-data)
url - URL, к которому мы будем выполнять обращение;
post-data - по умолчанию будет выполнен GET – запрос. Если в данном параметре будут указаны различные значения, то будет выполнен POST запрос с указанными в переменной данными;
Например:
exten => _X.,1,Set(C_RESULT=${CURL(//merionet.ru/rest?num=84991234567)})
Здесь мы выполним GET запрос по указанному URL, а результат сохраним в переменной C_RESULT.
Использование HTTPS в запросах
Иногда, HTTPS запросы могут не срабатывать, так как удаленная сторона будет проверять наш SSL – сертификат. Если поставить параметр ssl_verifypeer=0, то такой проверки не будет:
same => n,Set(CURLOPT(ssl_verifypeer)=0)
Как воспользоваться этим в диалплане?
Легко. С помощью функции GotoIf мы можем определить действие, которое отработает на базе результата cURL:
exten => _X.,1,Set(C_RESULT=${CURL(//merionet.ru/rest?num=84991234567)})
same => n,GotoIf($["${C_RESULT}" = "1"]?res1:res2)
same => n(res1),Verbose(CURL Result = 1)
same => n,Hangup
same => n(res2),Verbose(CURL Result != 1)
same => n,Hangup
Указанный код отправит GET - запрос на rest, в котором в параметре num передаст номер звонящего (можно указать соответствующую переменную диалплана Asterisk). В случае, если результатом выполнения запроса будет 1, то мы перейдем к выполнению шага res1, а противоположном случае, res2.
res_json для обработки JSON ответов
На самом деле, для API, является обычной практикой возврат ответа в виде JSON. Поэтому, нам следует преобразовать эти данные перед обработкой их. Для этого мы воспользуемся модулем res_json из JSON библиотеки, который создан для расширения базовых возможностей диалплана с точки зрения обработки JSON.
Почитайте материал об установке данного модуля по этой ссылке.
exten => _X.,1,Set(C_RESULT=${CURL(//merionet.ru/rest.json)})
same => n,Set(result=${JSONELEMENT(C_RESULT, result/somefield)})
same => n,GotoIf($["${result}" = "1"]?res1:res2)
same => n(res1),Verbose(CURL Result = 1)
same => n,Hangup
same => n(res2),Verbose(CURL Result != 1)
same => n,Hangup
Для теста, создайте у себя на web – сервере файл rest.json со следующим содержанием:
{
"result": {
"somefield": 1
}
}
Неисправности
Вы не можете запустить виртуальную машину и получаете сообщения об ошибках зависимости диска и отсутствии файла.
В случае отсутствия файлов вы видите такие ошибки, как:
Cannot open the disk '/vmfs/volumes/volume/vm/vm-000002.vmdk' or one of the snapshot disks it depends on.
Cannot open disk "/vmfs/volumes/volume/vm/vm-000002.vmdk": The parent virtual disk has been modified since the child was created (18).
В случае отсутствия файлов, в файле vmware.log виртуальной машины есть сообщения, похожие на:
vmx| DISKLIB-LINK : "myvm.vmdk" : failed to open (The system cannot find the file specified).
vmx| DISKLIB-CHAIN : "myvm.vmdk" : failed to open (The system cannot find the file specified).
В случае сбоя зависимости снимка диска, в файле vmware.log виртуальной машины не будет ошибки «Невозможно найти указанный файл» (cannot find the file specified), но Вы увидите сообщения о том, что родительский виртуальный диск был изменён:
Cannot open the disk '/vmfs/volumes/4a365b5d-eceda119-439b-000cfc0086f3/examplevm/examplevm-000002.vmdk' or one of the snapshot disks it depends on.
The parent virtual disk has been modified since the child was created.
Эти ошибки могут возникать, если дескриптор диска виртуальной машины (VMDK) или файл данных отсутствуют или цепочка снимков стала несовместимой.
Решение
Это решение разбито на 2 части, в зависимости от проблемы:
Вы не можете запустить виртуальную машину из-за ошибки system cannot find the file specified (Система не может найти указанный файл) или других ошибок, например - file not found(Файл не найден).
Вы не можете запустить виртуальную машину из-за того, что the parent virtual disk has been modified since the child was created (Родительский виртуальный диск был изменён с момента создания дочернего диска).
System cannot find the file specified
Вы должны убедиться, что файлы диска виртуальной машины представлены должным образом.
Для каждого диска, включая снимок диска, должен быть файл дескриптора в виде vmName.vmdk
Кроме того, для базового диска также должен существовать файл с расширением flat.vmdk или separse.vmdk в виде vmName-flat.vmdk или vmName-separse.vmdk.
Для снимка диска, должен быть файл с разрешением delta.vdmk или sesparse.vmdk в виде vmName-######-delta.vmdk или vmName-######-separse.vmdk.
Если файлы дескриптора отсутствуют, то Вам необходимо создать их заново.
Если файлы данных (-flat, -delta или –sparse) отсутствуют, возможно, потребуется восстановить виртуальную машину из резервной копии.
The parent virtual disk has been modified since the child was created
Эта проблема обычно возникает из-за несоответствия идентификатора содержимого (CID). Чтобы устранить несоответствие CID, необходимо отредактировать файлы дескрипторов VMDK, чтобы обеспечить согласованность цепочки снимков.
Дополнительная информация
Для дисков RDM не будет файла –flat или –sesparse для базового диска. Физический режим RDM будет иметь файл в виде vmName-rdmp.vmdk. Виртуальный режим RDM будет иметь файл в виде vmName-rdm.vmdk.
Если дескриптор RDMA отсутствует, его также можно создать заново.